7.6 Utilitaires Git - Réécrire l’historique

Modifier votre dernière validation est probablement la réécriture de l’historique que vous allez utiliser le plus souvent. Vous voudrez souvent faire deux choses basiques à votre dernier commit : modifier le message de validation ou changer le contenu que vous avez enregistré en ajoutant, modifiant ou supprimant des fichiers.

Si vous voulez seulement modifier votre dernier message de validation, c’est vraiment simple :

Cela ouvre votre éditeur de texte contenant votre dernier message, prêt à être modifié. Lorsque vous sauvegardez et fermez l’éditeur, Git enregistre la nouvelle validation contenant le message et en fait votre dernier commit.

Si vous voulez modifier le contenu de votre validation en ajoutant ou modifiant des fichiers, sûrement parce que vous avez oublié d’ajouter les fichiers nouvellement créés quand vous avez validé la première fois, la procédure fonctionne grosso-modo de la même manière. Vous indexez les modifications que vous voulez en exécutant git add ou git rm, et le prochain git commit --amend prendra votre index courant et en fera le contenu de votre nouvelle validation.

Vous devez être prudent avec cette technique car votre modification modifie également le SHA-1 du commit. Cela ressemble à un tout petit rebase. Ne modifiez pas votre dernière validation si vous l’avez déjà publiée !

Pour modifier une validation qui est plus loin dans votre historique, vous devez utiliser des outils plus complexes. Git ne contient pas d’outil de modification d’historique, mais vous pouvez utiliser l’outil rebase pour rebaser une suite de commits depuis la branche HEAD plutôt que de les déplacer vers une autre branche. Avec l’outil rebase interactif, vous pouvez vous arrêter après chaque commit que vous voulez modifier et changer le message, ajouter des fichiers ou quoi que ce soit que vous voulez. Vous pouvez exécuter rebase interactivement en ajoutant l’option -i à git rebase. Vous devez indiquer jusqu’à quand remonter dans votre historique en donnant à la commande le commit sur lequel vous voulez vous rebaser.

Par exemple, si vous voulez modifier les 3 derniers messages de validation ou n’importe lequel des messages dans ce groupe, vous fournissez à git rebase -i le parent du dernier commit que vous voulez éditer, qui est HEAD~2^ or HEAD~3. Il peut être plus facile de se souvenir de ~3, car vous essayez de modifier les 3 derniers commits, mais gardez à l’esprit que vous désignez le 4e, le parent du dernier commit que vous voulez modifier :

Souvenez-vous également que ceci est une commande de rebasage, chaque commit inclus dans l’intervalle HEAD~3..HEAD sera réécrit, que vous changiez le message ou non. N’incluez pas, dans cette commande, de commit que vous avez déjà poussé sur un serveur central. Le faire entraînera la confusion chez les autres développeurs en leur fournissant une version altérée des mêmes modifications.

Exécuter cette commande vous donne la liste des validations dans votre éditeur de texte, ce qui ressemble à :

Il est important de signaler que les commits sont listés dans l’ordre inverse de celui que vous voyez normalement en utilisant la commande log. Si vous exécutez la commande log, vous verrez quelque chose de ce genre :

Remarquez l’ordre inverse. Le rebasage interactif va créer un script à exécuter. Il commencera au commit que vous spécifiez sur la ligne de commande (HEAD~3) et refera les modifications introduites dans chacun des commits du début à la fin. Il ordonne donc le plus vieux au début, plutôt que le plus récent, car c’est celui qu’il refera en premier.

Vous devez éditer le script afin qu’il s’arrête au commit que vous voulez modifier. Pour cela, remplacer le mot « pick » par le mot « edit » pour chaque commit après lequel vous voulez que le script s’arrête. Par exemple, pour modifier uniquement le message du troisième commit, vous modifiez le fichier pour ressembler à :

Au moment où vous sauvegardez et quittez l’éditeur, Git revient au dernier commit de cette liste et vous laisse sur une ligne de commande avec le message suivant :

Ces instructions vous disent exactement quoi faire. Entrez :

Modifiez le message de commit et quittez l’éditeur. Puis exécutez :

Cette commande appliquera les deux autres commits automatiquement. Si vous remplacez « pick » en « edit » sur plusieurs lignes, vous pouvez répéter ces étapes pour chaque commit que vous avez marqué pour modification. Chaque fois, Git s’arrêtera, vous laissant modifier le commit et continuera lorsque vous aurez fini.

Vous pouvez également utiliser les rebasages interactifs afin de réordonner ou supprimer entièrement des commits. Si vous voulez supprimer le commit « added cat-file » et modifier l’ordre dans lequel les deux autres commits se trouvent dans l’historique, vous pouvez modifier le script de rebasage :

afin qu’il ressemble à ceci :

Lorsque vous sauvegardez et quittez l’éditeur, Git remet votre branche au niveau du parent de ces commits, applique 310154e puis f7f3f6d et s’arrête. Vous venez de modifier l’ordre de ces commits et de supprimer entièrement le commit « added cat-file ».

Il est également possible de prendre une série de commits et de les rassembler en un seul avec l’outil de rebasage interactif. Le script affiche des instructions utiles dans le message de rebasage :

Si, à la place de « pick » ou « edit », vous spécifiez « squash », Git applique cette modification et la modification juste précédente et fusionne les messages de validation. Donc, si vous voulez faire un seul commit de ces trois validations, vous faites en sorte que le script ressemble à ceci :

Lorsque vous sauvegardez et quittez l’éditeur, Git applique ces trois modifications et vous remontre l’éditeur contenant maintenant la fusion des 3 messages de validation :

Lorsque vous sauvegardez cela, vous obtenez un seul commit amenant les modifications des trois commits précédents.

Pour diviser un commit, il doit être défait, puis partiellement indexé et validé autant de fois que vous voulez pour en finir avec lui. Par exemple, supposons que vous voulez diviser le commit du milieu dans l’exemple des trois commits précédents. Plutôt que « updated README formatting and added blame », vous voulez le diviser en deux commits : « updated README formatting » pour le premier, et « added blame » pour le deuxième. Vous pouvez le faire avec le script rebase -i en remplaçant l’instruction sur le commit que vous voulez diviser en « edit » :

Puis, lorsque le script vous laisse accès à la ligne de commande, vous pouvez annuler (reset) ce commit et revalider les modifications que vous voulez pour créer plusieurs commits. En reprenant l’exemple, lorsque vous sauvegardez et quittez l’éditeur, Git revient au parent de votre premier commit de votre liste, applique le premier commit (f7f3f6d), applique le deuxième (310154e), et vous laisse accès à la console. Là, vous pouvez faire une réinitialisation mélangée (mixed reset) de ce commit avec git reset HEAD^, qui défait ce commit et laisse les fichiers modifiés non indexés. Maintenant, vous pouvez indexer et valider les fichiers sur plusieurs validations, et exécuter git rebase --continue quand vous avez fini :

Git applique le dernier commit (a5f4a0d) de votre script, et votre historique ressemblera alors à :

Une fois encore, ceci modifie les empreintes SHA-1 de tous les commits dans votre liste, soyez donc sûr qu’aucun commit de cette liste n’ait été poussé dans un dépôt partagé. Notez que le dernier commit (f7f3f6d) n’est pas modifié. Bien que ce commit soit affiché dans le script, parce qu’il a été marqué « pick » et a été appliqué avant toutes les modifications du rebasage, Git le laisse à l’identique.

Si vous souhaitez vous débarrasser d’un commit, vous pouvez le supprimer en utilisant le script rebase -i. Dans la liste des commits, placez le mot « drop » (lâcher en anglais) devant le commit que vous voulez supprimer (ou effacez tout simplement la ligne du script de rebasage) :

Tel que Git construit ses objets commits, supprimer ou altérer une commit va cause la réécriture de tous les commits qui le suivent. Plus vous remontez loin dans l’historique du dépôt, plus nombreux sont les commits qui doivent être recréés. Cela peut causer de nombreux conflits de fusion si vous avez de nombreux commits ultérieurs dans la séquence qui dépendent de celui que vous venez de supprimer.

Si à mi-chemin d’un rebasage cataclysmique, vous décidez que ce n’était tout compte fait pas une bonne idée, vous pouvez toujours tout arrêter. Tapez git rebase --abort, et votre dépôt reviendra à l’état précédent le début du rebasage.

Si vous finissez un rebasage et décidez que ce n’est pas ce que vous vouliez, vous pouvez encore utiliser git reflog pour retrouver une version antérieure de votre branche. Référez-vous à Récupération de données pour plus d’information sur la commande reflog.

Il existe une autre option de la réécriture d’historique que vous pouvez utiliser si vous avez besoin de réécrire un grand nombre de commits d’une manière scriptable ; par exemple, modifier globalement votre adresse mail ou supprimer un fichier de tous les commits. La commande est filter-branch, et elle peut réécrire des pans entiers de votre historique, vous ne devriez donc pas l’utiliser à moins que votre projet ne soit pas encore public ou que personne n’ait encore travaillé sur les commits que vous allez réécrire. Cependant, cela peut être très utile. Vous allez maintenant apprendre quelques usages communs pour vous donner une idée de ses capacités.