L’interactive rebase est parfois appelée le « couteau suisse » de Git – parce qu’elle contient tant d’outils différents, pour tant de cas d’utilisation différents ! Cependant, il y a un cas d’utilisation principal et primordial : le nettoyage de votre historique de commit local.

Tenez compte du mot « local » : il ne devrait être utilisé que pour le nettoyage de votre propre historique de commit local, par exemple avant d’intégrer une de vos branches de fonctionnalités dans une branche d’équipe. En revanche, il ne devrait PAS être utilisé sur l’historique des commit qui a déjà été poussé et partagé sur un dépôt distant. Interactive rebase est l’un de ces outils qui « réécrivent » l’historique de Git – et vous ne devriez pas le faire sur des commits qui ont déjà été partagés avec d’autres personnes.

Après ce petit message d’avertissement, examinons quelques exemples pratiques !

Note : pour une visualisation plus facile des scénarios et des flux de travail dans ce post, j’ai utilisé l’interface graphique de bureau Git « Tower » dans certaines de mes captures d’écran.

Correction d’un ancien message de commit

Parfois, vous remarquez une coquille dans un ancien message de commit – ou vous avez oublié de mentionner quelque chose dans la description qui est digne d’intérêt. Si nous parlions du tout dernier commit, nous aurions pu simplement utiliser l’option --amend de la commande git commit. Mais pour les commits plus anciens, vous devrez utiliser interactive rebase pour les modifier après coup.

Voici un exemple de message de commit qui a mal tourné et que nous voulons corriger :

Un mauvais message de commit qui doit être corrigé

La première étape de toute session interactive rebase est de déterminer quelle partie de l’historique des commits vous voulez manipuler. Pour reprendre l’exemple ci-dessus : afin de modifier ce mauvais commit, nous devons démarrer la session à son commit parent.

Démarrage de notre session interactive rebase

Nous pouvons maintenant alimenter le hash de ce commit de départ à la commande interactive rebase:

$ git rebase -i 0023cddd

Une fenêtre d’éditeur va maintenant s’ouvrir, contenant une liste des commits que vous venez de sélectionner pour la manipulation. Et ne soyez pas surpris car ils sont dans l’ordre inverse : dans une session interactive de rebasement, Git réappliquera les anciens commits, élément après élément – ce qui signifie que l’inversion de l’ordre est correcte du point de vue de Git.

Fenêtre d’éditeur avec les commits sélectionnés

Une autre chose importante à noter à propos de cette fenêtre d’éditeur : vous n’effectuez pas les manipulations réelles ici ! Ou, dans cet exemple concret, vous n’allez PAS modifier le message de commit ici. Au lieu de cela, vous marquez seulement le commit que vous voulez changer avec un mot-clé d’action. Dans notre cas, comme nous voulons changer le message d’un commit, nous marquons la ligne avec « reword ». Si vous sauvegardez et fermez ensuite cette fenêtre d’édition, une nouvelle fenêtre s’ouvrira, contenant le message de l’ancien commit. Il est maintenant temps de faire enfin vos modifications :

Finalement, nous pouvons faire nos modifications

Après avoir sauvegardé et fermé une fois de plus, la session interactive rebase est terminée et notre ancien message de commit a été corrigé !

Combinaison de plusieurs commits en un seul

Un autre cas d’utilisation de interactive rebase est lorsque vous voulez combiner plusieurs anciens commentaires en un seul. Bien que, bien sûr, la règle d’or du contrôle de version s’applique : dans la plupart des situations, il est bénéfique de créer des commits plus nombreux et plus petits au lieu de quelques gros. Cependant, comme avec tout, nous pourrions trouver que nous avons exagéré et que nous voulons maintenant fusionner deux ou plusieurs anciens commits en un seul.

Pour faire un exemple concret, disons que nous voulons combiner les commits sélectionnés suivants en un seul:

Combinons plusieurs commits en un

Comme dans notre premier cas, nous commençons par démarrer la session interactive de rebase au moins au commit parent de celui que nous voulons manipuler.

$ git rebase -i 2b504bee

De nouveau, une fenêtre d’éditeur s’ouvre, listant la partie de notre historique de commit que nous voulons manipuler :

Marquage des lignes avec « squash »

Le mot-clé d’action que nous allons utiliser ici s’appelle « squash ». Et il n’y a qu’une seule information importante que vous devez savoir sur le squash pour l’utiliser : la ligne que nous marquons avec le mot-clé « squash » sera combinée avec la ligne directement au-dessus. C’est pourquoi, comme vous pouvez le voir dans ma capture d’écran ci-dessus, j’ai marqué la ligne #2 avec « squash » afin de la combiner avec la ligne #1.

Nous pouvons maintenant enregistrer et fermer la fenêtre de l’éditeur et à nouveau regarder et une nouvelle fenêtre apparaître : on nous demande maintenant de fournir un message de commit pour le nouveau commit qui est créé en combinant ces deux anciens.

Saisie d’un nouveau message pour le nouveau commit écrasé

Après avoir enregistré et fermé cette fenêtre d’éditeur, vous verrez qu’un nouveau commit a été créé qui contient les changesets des deux anciens commits. Voila!

Réparation d’une erreur

Un autre cas d’utilisation de la rebase interactive est lorsque vous avez trouvé une erreur dans l’un de vos commits précédents. Et peu importe ce que vous avez exactement raté : vous pourriez avoir oublié d’ajouter une certaine modification, avoir dû supprimer un fichier, ou simplement avoir introduit une coquille…

La tendance naturelle, dans une telle situation, est de simplement créer un nouveau commit qui corrige l’erreur. Mais d’un autre côté, cela va mettre le désordre dans notre historique de commit : faire un commit original, et ensuite ajouter un commit  » pansement  » juste pour corriger quelques erreurs… c’est une façon désordonnée de travailler. Votre historique de commit deviendra bientôt difficile à comprendre, parce qu’il est jonché de tous ces petits  » commits de réparation rapide  » !

C’est là que  » fixup « , un des outils fournis avec la rebase interactive, se révèle très pratique. Fixup prend ce commit « quick fix », applique ses changements au commit original (le corrigeant ainsi), puis se débarrasse du commit pansement :

Comment « fixup » fonctionne

Après avoir terminé, il semble qu’il n’y ait jamais eu de problème avec notre commit original ! Donc, marchons à travers cela en utilisant un exemple pratique.

La première étape est de faire tout ce qui est nécessaire pour corriger le problème : cela pourrait signifier ajouter un nouveau fichier, apporter des modifications aux fichiers existants, supprimer les fichiers obsolètes… vous avez « juste » besoin de produire les changements qui corrigent l’erreur.

L’étape suivante consiste à commiter ces changements dans le dépôt – mais avec un petit plus : lors du commit, nous allons utiliser le drapeau --fixup et indiquer à Git le hash de notre mauvais commit :

$ git add corrections.txt$ git commit --fixup 2b504bee

Lorsque vous jetez maintenant un coup d’œil à l’historique du commit, vous verrez qu’un commit d’apparence plutôt ordinaire a été créé – probablement pas la magie et les feux d’artifice auxquels vous vous attendiez. Mais si vous regardez de plus près, vous verrez que quelque chose se passe : le nouveau commit a été automatiquement précédé de « fixup ! » et du sujet de notre mauvais commit.

Le commit original et le fix commit

La troisième étape consiste maintenant à lancer la session interactive de rebasement. Encore une fois, nous choisissons le parent de notre mauvais commit comme point de départ…

$ git rebase -i 0023cddd --autosquash

… et comme deuxième partie de la sauce secrète, nous utilisons l’option --autosquash. Cette option fait en sorte que nous n’ayons rien à faire dans la fenêtre de l’éditeur qui est maintenant ouverte. Regardez attentivement la situation:

Notre commit de réparation est marqué « fixup » et trié à la bonne position

Vous verrez que Git a automatiquement fait deux choses pour nous:

1. Il a marqué notre commit de réparation comme « fixup. »
2. Il a réorganisé les lignes de sorte que notre commit de pansement apparaisse directement sous notre mauvais commit. C’est parce que fixup fonctionne exactement comme squash dans la mesure où il se combine avec la ligne au-dessus.

En d’autres termes : il n’y a rien à faire pour nous que de sauvegarder et de fermer la fenêtre de l’éditeur.

Regardons à nouveau l’historique des commits :

Une fin heureuse !

Non seulement notre mauvais commit initial contient maintenant les changements de notre band-aid commit. Mais en plus de cela, le vilain commit de pansement a disparu de l’historique des commits ! Tout est beau et propre, comme s’il n’y avait jamais eu de problème !

Découvrez la puissance de rebase interactif

Il y a beaucoup de cas d’utilisation pour rebase interactif – et la plupart d’entre eux dans le département de la « réparation des erreurs ». Pour un aperçu d’autres choses utiles que vous pouvez faire, je recommande le « First Aid Kit for Git » gratuit : il s’agit d’une collection de courtes vidéos (2-3 min par épisode) qui vous aident à apprendre à annuler les erreurs en utilisant interactive rebase et d’autres outils Git.

Note de l’éditeur : j’ai dû utiliser interactive rebase lors de la révision de ce même post ! L’un de mes commits incluait une image qui était supérieure à 1MB, ce qui est contraire aux règles du projet de site web GitLab. J’ai dû revenir en arrière et corriger ce commit pour inclure une image de taille correcte à la place. Merci pour la leçon, univers ! 😁

Plus de trucs et astuces Git

• 15 astuces Git pour améliorer votre flux de travail
• Comment Git Partial Clone vous permet de récupérer uniquement le gros fichier dont vous avez besoin
• Git arrive ! 6 Erreurs communes de Git et comment les corriger

A propos de l’auteur invité

Tobias Günther est le PDG de Tower, le populaire client de bureau Git qui aide plus de 100 000 développeurs dans le monde à être plus productifs avec Git.

Image de couverture par David Taljat sur Pexels

.