Git Commit Fixup, ou comment garder un historique propre
TL; DR si je résume en 4 commandes l’article, ça donne ça, sinon je vous laisse lire le reste :)
git add .
git commit --fixup <votre_sha1_de_commit>
git rebase -i --autosquash <votre_sha1_de_commit>~
git push --force
Corriger / Editer / Améliorer un commit simplement
Vous avez sans doutes déjà rencontré cette situation où, pendant une revue de code ou une pull request, vous aviez des choses à modifier / corriger / améliorer, et qu’une fois ces modifications faites, vous ne saviez pas comment les ranger, vous ou quelqu’un qui travaille avec vous.
AAAAAHHH Panique ! C’est souvent à cette étape que certaines personnes ne maitrisant pas Git peuvent se perdre et faire un amend du dernier commit, ou encore créer le fameux commit de “Prise en compte des retours”. Arf, c’est plein de bonne volonté mais ça n’aidera pas à rendre votre historique plus propre.
Toujours dans le but de bien organiser votre code et de simplifier la lecture de votre historique Git, le commit fixup peut vite devenir votre meilleur ami.
Le terme fixup ne doit pas vous être inconnu, en effet il est déjà présent dans les rebases. Ici, je vais vous parler du commit de fixup, bien plus simple à utiliser. Perso je l’utilise beaucoup dans les retours de Pull Request pour mettre les modifications que je fais dans les commits appropriés.
J’écrirai sans doute un article par la suite là dessus pour vous montrer comment je procède pour organiser mon historique de commit avant une Pull Request.
Voyons ensemble comment cela fonctionne.
Je viens de pousser ma Pull Request, quelques reviewers viennent de la passer en revue et j’ai des retours à faire sur mon code, je vais donc sur la branche de ma Feature, en veillant à être sur la dernière version de mon code.
A partir de là, j’effectue les modifications sur mon code pour répondre aux remarques, je lance mes tests, tout est OK. Jusqu’ici rien d’extra, c’est juste cool je viens d’améliorer les choses.
Puis arrive le moment de réorganiser tout ça. Je fais un petit git status pour savoir où j’en suis
Coup de bol, toutes ces modifications concernent une remarque pour renommer une variable. Chouette je peux donc tout ajouter en bloc avec mon git add . (sinon j’aurais dû spécifier les fichier que je voulais embarquer dans mon fixup à l’aide du git add <monFichier>)
git add .
Maintenant je regarde le commit que je dois fixer, donc je fais un petit
git log --oneline
pour récupérer le sha1 du commit en question
Arf, pas de chance, ce n’est pas le dernier donc pas de commit amend, en même temps… on est dans un tuto fixup !
Du coup ici je souhaite éditer le 2eme commit donc je récupère son sha1 => 4f6cbe1
Et le lance un
git commit --fixup 4f6cbe1
C’est comme cela que j’informe git de mon intention de vouloir fixer ce commit avec toutes les modification que j’ai ajoutées plus tôt
Si je fais un git log, cette fois on constate que j’ai un nouveau commit :
En effet, cela m’a créé un nouveau commit, mais celui-ci est prefixé par “fixup !”
Et c’est ici que la magie opère, il ne me reste qu’à lancer un
git rebase -i --autosquash 4f6cbe1~
je précise le commit duquel je souhaite démarrer mon rebase, ici 4f6cbe correspond au premier commit que j’ai fait pour ma nouvelle feature, j’ajoute le ~ pour qu’il soit inclut dans le rebase.
Ma console s’ouvre avec tout le plan d’action de votre rebase déjà bien comme il faut, aux ptits’ oignons !
Le rebase sait qu’il devra faire un fixup de ce dernier commit préfixé, il se charge donc de le positionner où il faut dans la liste. Il ne reste plus qu’à valider que c’est bon pour vous et laisser le rebase faire sa petite vie tranquilou.
En refaisant un git log cette fois, je constate que l’édition du commit est bonne par le changement du sha1
Il ne me reste plus qu’à jouer ma commande préférée :
git push --force
(L’utilisation du force est obligatoire car vos SHA1 de commit auront changés et qu’il y aura confusion pour Git si vous ne le faites pas)
Et voilà le tour est joué, c’est comme si j’avais bien fait du premier coup, mais c’est surtout que je n’ai pas un 2ème commit qui prendrait juste les modifications, ce qui peut poser problème dans un cas de cherry-pick, il faudrait en effet prendre le commit de base ainsi que toutes ses modifications, et sur des choses plus complexes cela peut vite devenir infernal, et ça sans parler de la satisfaction d’avoir un historique super propre et des commits bien rangés.
❤️ Des bisous, du love ❤️ et amusez vous bien !
