Aide-mémoire Git

À quoi sert vraiment un aide-mémoire Git

Git compte bien plus d'une centaine de commandes de porcelaine, mais la plupart des ingénieurs utilisent les mêmes vingt ou trente chaque jour et n'ont recours aux autres que quelques fois par an. Un aide-mémoire ne remplace pas la compréhension du modèle ; il existe pour que les commandes que vous comprenez déjà restent à une touche de distance plutôt qu'à un onglet de navigateur et trois réponses Stack Overflow.

La référence de cette page est groupée selon le déroulement réel du travail : configuration d'un dépôt, la boucle de commit que vous lancez des dizaines de fois par jour, les branches, la communication avec un dépôt distant, la lecture de l'historique, et vous sortir de situation difficile. Saisissez dans la zone de filtre et la liste se réduit à la fois sur le texte de la commande et sa description, donc rechercher « stash », « force » ou « undo » fait apparaître les lignes pertinentes immédiatement. Chaque ligne possède un bouton de copie, car retaper une commande contenant un --force-with-lease est précisément ce qui provoque les fautes de frappe.

Le modèle mental derrière les commandes

Presque chaque commande Git a un sens dès que vous gardez trois endroits en tête. L'arbre de travail est les fichiers sur disque tels que vous les voyez dans votre éditeur. L'index — aussi appelé zone de préparation — est l'instantané que vous assemblez pour le prochain commit. Le dépôt est la chaîne immuable de commits déjà enregistrés. git add déplace le contenu de l'arbre de travail vers l'index, git commit transforme l'index en un nouveau commit, et git restore renvoie le contenu dans l'autre sens.

Les branches sont la deuxième idée, et elles sont plus simples qu'elles n'en ont l'air : une branche est simplement un pointeur mobile vers un commit, et HEAD est un pointeur vers la branche sur laquelle vous êtes. Créer une branche ne coûte rien car elle écrit un seul fichier contenant un hash de quarante caractères. C'est pourquoi git switch -c est peu coûteux, suffisant pour une expérience de cinq minutes.

La fusion et le rebasage combinent tous deux le travail de deux branches ; ils diffèrent dans ce qu'ils enregistrent. Une fusion conserve les deux historiques et ajoute un commit qui les joint, ce qui est honnête mais produit un graphe tressé. Un rebasage réécrit vos commits pour qu'ils apparaissent avoir été écrits au-dessus de l'autre branche, ce qui produit une ligne droite propre mais change les hash des commits — c'est exactement pourquoi vous ne rebasez jamais de commits que d'autres ont déjà récupérés.

Récupérer quand quelque chose tourne mal

La chose la plus utile à savoir sur Git est qu'il perd très rarement un travail commité. Tant qu'un changement a été commité à un moment donné, git reflog vous montrera le hash, et git switch -c rescue <hash> le ramènera. Ce filet de sécurité couvre les rebasages ratés, un reset --hard accidentel après un commit, et les branches supprimées un peu trop hâtivement.

Les opérations dangereuses sont celles qui touchent un travail non commité : git reset --hard, git checkout -- sur un fichier modifié, et git clean -fd. Aucun de ces changements n'a jamais été enregistré, donc le reflog ne pointe vers rien. L'habitude à prendre est de committer tôt et souvent sur une branche temporaire, ou de faire git stash push avant toute expérience. Un commit que vous écrasez plus tard ne coûte rien ; un après-midi de travail non commité ne revient pas.

Sur les branches partagées, préférez git revert à la réécriture de l'historique. Il enregistre un nouveau commit qui inverse l'ancien, donc le clone de chacun reste valide. Réservez --force-with-lease à vos propres branches de fonctionnalités, et notez que c'est de manière significative plus sûr qu'un --force simple : il refuse de s'exécuter si le distant a bougé depuis votre dernier fetch, ce qui est précisément le cas où un force push simple détruirait silencieusement les commits d'un collègue.