Améliorez votre workflow avec Git rebase

Les merge requests permettent à l'équipe de développement logiciel de passer en revue les modifications du code avant de les intégrer au projet principal. De nos jours, cette tâche prend beaucoup de temps. Découvrez comment Git rebase peut vous aider à accélérer ces cycles de revues de code. Commençons par certaines considérations relatives au workflow.

Comment rectifier le code d'une merge request ?

Un développeur qui a travaillé sur des modifications de code et a créé une merge request pour les intégrer au projet devra souvent procéder à des ajustements ou des corrections. Pourquoi ? Parce que certains tests peuvent échouer, des bogues peuvent être découverts, ou les relecteurs peuvent suggérer des améliorations et repérer des anomalies.

Méthode simple, mais désordonnée : multiplier les validations

Pour rectifier le code de la merge request, vous pouvez simplement apporter d'autres modifications par l'intermédiaire de nouvelles validations sur la branche utilisée pour créer la merge request, puis effectuer à nouveau un push de la branche afin de mettre à jour la merge request.

Cependant, lorsque plusieurs validations ont été ajoutées de cette manière, la merge request peut devenir un vrai défi :

• Il est difficile d'effectuer une revue de code de toutes les modifications en les examinant toutes ensemble.
• Il est difficile d'examiner les validations séparément, car elles peuvent contenir des modifications différentes sans rapport entre elles, voire de plusieurs versions d'un même code.

Les relecteurs préfèrent souvent examiner les modifications de code réparties sur plusieurs petites validations autonomes pouvant faire l'objet de revues de code individuelles.

Méthode de professionnels : rebaser !

Le meilleur moyen de préparer ou de rectifier le code d'une merge request consiste à toujours s'assurer que chaque validation contient de petites modifications, indépendantes et faciles à réviser.

Chaque validation de la branche peut nécessiter des ajustements, plutôt que d'ajouter de nouvelles validations. De prime abord plus complexe et fastidieuse, cette approche dispose d'une botte secrète : git rebase !

Rectifier vos validations avec git rebase

Si votre objectif consiste à créer une merge request à partir d'une série de petites validations indépendantes, il est possible que votre branche nécessite un travail précis de rectification avant que ses validations ne soient suffisamment fiables. Une fois les validations prêtes, vous pouvez effectuer un push de la branche et mettre à jour ou créer une merge request avec cette branche.

Démarrer un rebasage interactif

Si votre branche est basée sur la branche principale main, la commande pour rectifier votre branche est la suivante :

git rebase -i main

Créer un alias Git, un alias shell ou encore une fonction shell pour cette commande pourra s'avérer très pratique dans la mesure où vous l'utiliserez très souvent.

L'option -i passée à git rebase est un alias pour --interactive. Elle lance un rebasage « interactif » qui ouvrira votre éditeur de code. Vous y trouverez une liste des validations de votre branche, suivie de lignes de commentaires commençant par #.

Voici à quoi ressemble la liste des validations :

pick 1aac632db2 first commit subject
pick a385014ad4 second commit subject
pick 6af12a88cf other commit subject
pick 5cd121e2a1 last commit subject

Ces lignes sont des instructions sur la façon dont git rebase doit traiter ces validations. Les validations sont listées dans l'ordre chronologique, la validation la plus ancienne apparaissant en tête. (Cet ordre est l'inverse de l'ordre par défaut de git log.) Que contiennent ces lignes ?

• Une instruction (dans cet exemple, pick) qui indique à Git l'action à entreprendre
• Un identifiant abrégé de la validation
• Un sujet qui vous aide à identifier le contenu de la validation

Modifier la liste des instructions

Vous pouvez modifier ces instructions ! Lorsque vous quittez votre éditeur de texte, git rebase lit les instructions que vous venez de modifier et les exécute dans l'ordre pour recréer votre branche comme vous le souhaitez.

Après les instructions pour toutes les validations, une série de lignes de commentaires explique comment modifier les lignes d'instruction, et comment chaque instruction affectera votre branche :

• Si vous supprimez la totalité de la ligne d'instruction d'une validation de la liste, cette validation ne sera pas recréée.
• Si vous réorganisez les lignes d'instruction, les validations seront recréées dans l'ordre que vous spécifiez.
• Si vous changez l'action de l'instruction pick en la remplaçant par exemple par squash ou reword, Git effectuera l'action que vous spécifiez sur cette validation.
• Vous pouvez même ajouter de nouvelles lignes d'instruction avant, après ou entre les lignes actuelles.

Si les lignes de commentaires ne sont pas suffisantes, vous pouvez trouver de plus amples informations sur ce que vous pouvez faire et le fonctionnement du rebasage Git dans les ressources suivantes :

• Le chapitre Utilitaires Git - Réécrire l'historique du livre « Pro Git ».
• Le chapitre Mode interactif de la documentation git rebase.

Continuer ou abandonner le rebasage

Un rebasage interactif peut être interrompu en cas de conflit (comme le ferait un rebasage standard) ou si vous avez utilisé une instruction telle que edit dans la ligne d'instruction. Cela vous permet d'apporter certaines modifications : vous pouvez, par exemple, diviser la validation actuelle en deux validations distinctes ou résoudre le conflit de rebasage le cas échéant. Ensuite, deux options s'offrent à vous :

• Continuer le rebasage interactif à l'aide de la commande git rebase --continue.
• Abandonner le rebasage à l'aide de la commande git rebase --abort.

(Ces options git rebase fonctionnent également lorsqu'un rebasage standard, non interactif, s'arrête).

Autres conseils et avantages

Essayer les différentes instructions

Nous vous recommandons d'essayer les différentes instructions que vous pouvez utiliser dans chaque ligne d'instruction, en particulier reword, edit, squash et fixup. Vous pouvez utiliser les versions abrégées de ces instructions : r, e, s et f.

Exécuter des commandes shell dans votre rebasage

Vous avez peut-être remarqué l'instruction exec <command> qui vous permet d'exécuter une commande shell quelle qu'elle soit à tout moment pendant le rebasage interactif. Cette commande sera plus utile pour les rebasages non interactifs, par exemple :

git rebase --exec 'make test' main

(Il ne s'agit pas d'un rebasage interactif, car il ne contient pas l'option -i).

L'option --exec <command> vous permet d'exécuter une commande shell après chaque validation rebasée, avec un arrêt du rebase dans le cas où la commande shell échoue (ce qui est signalé par un code de sortie différent de zéro).

Tester l'ensemble de vos validations

En passant la commande adéquate qui compile votre logiciel et exécute ses tests (par exemple, make test) à l'option --exec, vous pouvez vérifier que chaque validation dans votre branche se compile correctement et passe les tests.

Si la commande make test échoue, le processus de rebasage s'arrêtera. Vous pouvez alors corriger la validation en cours immédiatement, puis poursuivre le rebasage afin de tester les validations suivantes.

Vérifier que la compilation de chaque validation s'effectue correctement et passe tous les tests permet de s'assurer que votre code reste opérationnel. Ceci est particulièrement utile si vous souhaitez utiliser Git bisect quand vous rencontrez des régressions.

Conclusion

Dans Git, le rebasage est un outil très polyvalent et très utile pour rectifier le code des validations. Il permet de mettre en place un workflow avec des modifications qualitatives proposées dans des validations et des merge requests bien structurées. Développeurs et relecteurs n'en seront que plus efficaces. Les revues de code et le débogage gagnent également en facilité et en efficacité.