Apprendre Git : 3 commandes pour améliorer vos compétences

Apprenez à utiliser git squash, git rebase et git cerise-pick.

Lorsque je parle de Git aux gens, presque tout le monde réagit fortement à la commande git rebase. Cette commande a amené de nombreuses personnes à changer de répertoire, à supprimer le référentiel et à simplement re-cloner pour recommencer. Je pense que cela vient d'idées fausses sur le fonctionnement réel du branchement, d'une interface par défaut assez terrible et de certains conflits de fusion qui gâchent les choses.

Courge Git

Si vous avez déjà effectué de nombreux commits localement et souhaiteriez pouvoir les regrouper tous en un seul commit, vous avez de la chance. Git appelle ce concept « écraser les commits ». J'ai découvert le concept en travaillant sur la documentation. Il m'a fallu plus d'une douzaine de commits pour enfin obtenir un peu de démarque. Le responsable du dépôt ne voulait pas voir toutes mes tentatives encombrer l'historique du projet, alors on m'a dit de "simplement écraser vos commits".

L’écraser semblait être un plan solide. Il n’y avait qu’un seul problème. Je ne savais pas comment faire. En tant que nouveau venu sur Git, j'ai fait ce que n'importe qui ferait. J'ai consulté le manuel de squash et j'ai immédiatement rencontré un problème :

$ man git-squash
> No manual entry for git-squash

Il s'avère qu'on ne m'a pas demandé d'exécuter une commande Git appelée squash, on m'a demandé d'exécuter une commande entièrement distincte qui, à la fin, combinerait tous mes commits en un seul. Il s'agit d'un scénario courant : quelqu'un qui utilise un outil depuis un certain temps utilise du jargon ou fait référence à un concept qui, pour lui, est absolument clair, mais qui n'est pas évident pour quelqu'un qui découvre la technologie.

Conceptuellement, cela ressemblerait à ceci :

Photos de Dan Burton sur Unsplash

Je présente les choses de cette façon pour vous encourager à comprendre que vous n'êtes certainement pas la première ou la dernière personne à être dérouté par Git ou par quelqu'un qui parle de Git. Vous pouvez demander des éclaircissements et de l'aide pour trouver la bonne documentation. Ce que le responsable de la documentation voulait dire en réalité, c'était "utiliser le rebase Git pour regrouper les commits en un seul".

Rebase Git

La commande git rebase supprime une chaîne de validations de son premier parent et la place à la fin d'une autre chaîne de validations, combinant les deux chaînes de validations en une seule longue chaîne, au lieu de deux chaînes parallèles. Je me rends compte que c'est une déclaration dense.

Si vous repensez à la façon dont les commits Git sont enchaînés, vous pouvez voir que toute branche autre que votre branche main initiale a un commit parent qui sert de "base" de cette chaîne. Le rebasage est l'acte de faire du dernier commit d'une autre chaîne le nouveau commit "de base" pour une branche spécifiée.

Vous êtes peut-être déjà plus familier avec la fusion Git. Jetez un œil à la façon dont le site git-scm.com explique la différence :

(Git-scm.com, CC BY-SA 3.0)

Dans cet exemple de fusion, Git conserve la chaîne de validations affichée dans l'image comme C4, qui a un parent de C2, lors de la combinaison des modifications dans C3 pour créer une toute nouvelle validation, C5. Le pointeur de branchement pour « expérimentation » existe toujours et pointe toujours vers C4.

Le rebase dans cet exemple montre une situation similaire dans laquelle C4 existait d'abord en tant que branche distincte avec un parent de C2. Mais ensuite, au lieu de fusionner avec le code de C3, cela fait de C3 le nouveau parent de C4, ce qui entraîne un nouveau commit appelé C4. Notamment, le pointeur de branchement "main" n'a pas encore bougé. Pour que Git déplace le pointeur vers la fin de la chaîne, actuellement pointée par « experiment », vous devez également effectuer une fusion.

Rebase ne remplace pas la fusion. C'est un outil permettant de créer des historiques plus propres à utiliser conjointement avec la fusion.

Le rebase interactif est votre meilleur ami !

L'une des parties les plus effrayantes de l'exécution d'un rebase à partir de la ligne de commande est l'interface horrible. L'exécution de la commande git rebase fonctionne ou explose. Il n'y a pas beaucoup de retours ni de moyens de garantir qu'il fait exactement ce que vous voulez. Heureusement, la commande rebase et de nombreuses autres commandes Git ont un mode interactif, que vous pouvez appeler avec le paramètre -i' ou –interactive`.

(Dwayne McDaniel, CC BY-SA 4.0)

Lorsque vous invoquez le mode interactif, le rebase se transforme d'une terrifiante boîte noire en un menu d'options qui vous permet de faire plusieurs choses sur la chaîne de commits que vous rebasez. Pour chaque commit, vous pouvez choisir de :

Choisir : incluez-le tel quel
Reformuler : réécrire le message de validation
Edit : apportez d'autres modifications aux fichiers dans le commit avant la fin du rebase
Squash : écrasez plusieurs commits en un seul commit, en conservant tous les messages de commit
Correction : écrasez plusieurs commits en un seul, mais conservez simplement le dernier message de commit
Drop : supprimer ce commit

Personnellement, j'aime la façon dont l'extension open source GitLens pour VS Code présente les options avec des listes déroulantes, mais Git vous permet d'attribuer ces options à l'aide de n'importe quel éditeur. Pour les outils texte uniquement comme Emacs ou Vim, vous devez saisir la sélection plutôt que de la choisir dans un menu, mais le résultat final est toujours le même.

Quand rebaser

Savoir quand rebaser est aussi important que savoir comment rebaser. En vérité, si vous ne vous souciez pas du fait que vos historiques de dépôt soient un peu désordonnés, vous n'effectuerez peut-être jamais de rebase. Mais si vous souhaitez créer des historiques plus propres et avoir moins de commits qui encombrent votre vue graphique, il existe une règle empirique claire à toujours garder à l'esprit :

"Ne rebasez pas les commits qui existent en dehors de votre référentiel et sur lesquels des personnes peuvent avoir basé leur travail."

Si vous suivez cette directive, tout ira bien.

En termes simples, si vous créez une branche locale pour faire votre travail, n'hésitez pas à la rebaser autant que vous le souhaitez. Mais dès que cette branche est poussée, ne la rebasez pas. Cela dépend vraiment de vous.

J'espère que vous avez trouvé cela utile pour comprendre le fonctionnement de la commande git rebase et que vous pourrez l'utiliser avec plus de confiance. Comme pour toute commande Git, la pratique est le seul véritable moyen d’apprendre et de comprendre ce qui se passe. Je vous encourage à braver et à expérimenter le rebase interactif !

Git cerise-pick

La plupart des développeurs ont engagé du travail pour se rendre compte qu'ils travaillaient sur la mauvaise branche. Idéalement, ils pourraient simplement récupérer ce commit et le déplacer vers la bonne branche. C'est exactement ce que fait git cherry-pick.

Le triage est l'art de rebaser des commits uniques. C'était un modèle si courant qu'ils lui ont donné son propre commandement.

(Équipe Crossroadsphotototeam, CC BY-SA 2.0)

Pour effectuer un choix, indiquez simplement à Git l'ID du commit que vous souhaitez déplacer vers "ici", là où pointe HEAD :

$ git cherry-pick <target-ref>

En cas de problème, la récupération est simple, grâce aux messages d'erreur fournis par Git :

$ git cherry-pick -i 2bc01cd
Auto-merging README.md
CONFLICT (content): Merge conflict in README.md
error: could not apply 2bc01cd… added EOF lines
hint: After resolving the conflicts, mark them with
hint: "git add/rm ", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".
$ git cherry-pick --abort

Obtenez plus de puissance

La commande git rebase est une partie puissante de l'utilitaire Git. Il est probablement préférable de s'entraîner à l'utiliser avec un référentiel de test avant de devoir l'utiliser sous contrainte, mais une fois que vous serez familiarisé avec ses concepts et son flux de travail, vous pourrez contribuer à fournir un historique clair du développement d'un référentiel.