Git fixup quand on connait pas
Ça va être court : je vais parler de fixup automatique dans Git.
Pourquoi faire du fixup
J’ai pour habitude de beaucoup faire de fixup sur les rebase interactifs, quand je me rends compte que j’ai un état non complet sur l’un de mes commits, ce qui arrive souvent. Si c’est le dernier commit, un git commit --amend suffit. Si un ou plusieurs commit(s) se sont intercalés entre deux, alors il faudra faire un rebase interactif pour transformer l’historique.
J’ai pris cette habitude car même s’il m’arrive d’avoir de gros développements, je préfère faire de petits commits, mais au fil de l’eau ce n’est pas évident, ou alors on oublie quelque chose. Il faut souvent donc retravailler son historique localement avant de le publier.
À la main
Il fut un temps pas si lointain (le week-end dernier) où je faisais du fixup ‘à la main’. Dans ce cas, on fait un git log --oneline pour trouver le SHA1 du commit à compléter, on git add ce que l’on a oublié puis on fait git commit -m "fixup SHA1". Pour modifier réellement le commit, on fait un git rebase -i origin/<branch> pour déplacer le commit là où ça va bien (on s’aide du SHA1 dans le message du commit) et on modifie son utisation de pick à f(ixup).
Quand on connaît
Le truc c’est que c’est souvent long et chiant : je fais rarement mon rebase sur 4 commits. Mais tout ça peut se faire automatiquement…
On peut utiliser l’option --fixup=<SHA1> sur la commande git commit pour préciser que le commit courant va servir de fixup au commit <SHA1>. Sachant que <SHA1> peut être HEAD~4 car il va mettre en message de commit le message du commit à corriger.
Ensuite, l’option --autosquash sur le rebase interactif. Elle permet d’automatiquement réorganiser les commits dans le rebase interatif pour mettre les commits avec comme message fixup! <SHA1>|"message" après le commit fixup. Donc plus besoin de modifier à la main le placement des commits de correction.
Et Voilà !
Avec simplement 2 options à des commandes, mon collègue Alexandre Garnier m’a fait gagner au moins 15min par semaine et des appréhensions en moins !
Du même coup, ça s’est retrouvé sur mes alias :
|
|
Je vous conseille fortement d’avoir un historique propre lors de votre publication (push). Un historique clair avec des messages de commits correctement formatés permet de lire et comprendre le dépôt de code avec un git log --oneline. Ça en vaut la peine !