Squasher ses commits Git

Pour ne pas retrouver ses commits de travail dans votre branche de production, il est essentiel de squasher ces commits avant de fusionner votre branche (cf l’image d’illustration! 😉 ). Si vous ne savez pas ce que ce terme signifie ou comment l’appliquer, cet article est fait pour vous! On verra dans un premier temps ce que “squasher des commits” signifie, pourquoi c’est important et enfin on verra comment le faire avec des exemples concrets 🙂 

I. Définition

Squasher des commits signifie regrouper plusieurs commits en un seul. Si vous avez 3 commits A – B – C et que vous les regroupez B et C dans le commit A, vous avez “Squashé vos commits”.

II. Quelle utilité?

On va prendre un exemple très simple: imaginons que j’ai une issue à réaliser dont l’objectif est d’ajouter le nom et l’URL du site dans le README d’un projet quelconque. 

Voici une situation qui pourrait arriver si je suis très étourdis:

Je me dis: “c’est super simple je vais faire vite” et j’ajoute le nom du site dans le README en oubliant de mettre l’URL.

Je m’en aperçois et je la rajoute (je rajoute donc un commit). 

Toujours très étourdis, je fais  une faute à l’URL!

Encore une fois je m’en aperçois et je la corrige dans un autre commit.

Enfin, Vinvin relit ma merge Request et me fait remarquer qu’il faudrait un “é” à “Apero”.

Je prends en compte son retour et le modifie dans un commit, ça y est je peux fusionner ma branche dans Master!

Voici les commits générés:

Voici les diffs:

Ici, si je fusionne, je vais me retrouver avec 4 commits supplémentaires (en plus de l’éventuel commit de fusion) dans Master.

Quelle est la plus-value d’avoir les commits “Ajout accent ..”,”Ajout URL..” etc.. dans l’historique? Cela va “polluer” l’historique en ajoutant des commits inutiles. 

Voici l’historique des commits de ma branche Master après fusion en l’état:

Un seul commit appelé “Ajout du nom du site et de son URL dans le README” serait suffisant!

Est-ce que c’est si grave que ça ?

Il y a d’abord l’impact évident: lorsque je regarde ma branche principale (master ou main par exemple), si personne ne squash ses commits, on se retrouve avec énormément de commits peu parlants. Il est donc difficile de savoir ce qui a été effectué, et ce qui aurait pu causer d’éventuelles régressions par exemple.

Ensuite, je vais vous parler très concrètement du désavantage que j’y vois de mon point de vu de développeur: quand je veux savoir pourquoi une ligne de code a été rajoutée, il m’arrive de vouloir voir le contenu du commit dans lequel cette ligne a été introduite pour comprendre son rôle et pourquoi elle est présente. 

Lorsque la ligne de code qui me pose question a été introduite dans un énorme commit peu parlant, je vais mettre du temps pour comprendre pourquoi elle a été introduite et dans quel contexte.

Au contraire, s’il y a plein de commits (ce qui arrive souvent lorsqu’on ne squash pas ses commits), je vais devoir regarder plein de commits du type “fix typo”,”prise en compte retour MR 1”, “prise en compte retour MR 2” et je vais devoir inspecter le contenu de tous ces commits pour comprendre ce contexte.

Si on reprend l’exemple évoqué précédemment on a:

Cette perte de temps pourrait être évitée si les commits étaient clairs, c’est-à-dire qu’ils forment un groupe de sens de modification avec un message clair et c’est exactement ce que permet de faire le squash de commits.

---

III. Comment Squasher ses commits?

Mise en garde: avant de squasher, assurez vous bien que personne d’autre ne travaille sur votre branche, sinon il y aura des divergences d’historique qui vont être embêtantes! 

Très concrètement, une personne qui a pull la branche avant le push d’un squash ne pourra pas pull ni push simplement son travail s’il continue de développer sur cette branche.

C’est pour cette raison que je vous conseille de le faire juste avant de merge votre branche 🙂

Je vous conseille de lire la façon de faire manuellement même si vous ne souhaitez pas l’utiliser à l’avenir car elle vous permettra de comprendre comment un Squash fonctionne 😉

1. Squasher manuellement en ligne de commande

On reprend l’exemple précédent, on a les commits suivants (sortie de la commande git log):

Ici, on va regrouper les 4 commits qu’on a généré dans un seul commit: le premier. On renommera par la même occasion ce commit pour qu’il soit plus parlant.

Pour cela, on va faire un rebase interactif à partir du commit qui précède le commit qu’on veut garder. Ici c’est le commit initial avec le hash 40c7b53b0c2046d0d79c605050f5b12cc4cda4ef.

On va donc exécuter la commande suivante:

git rebase -i 40c7b53b0c2046d0d79c605050f5b12cc4cda4ef

Un éditeur s’ouvre alors:

Le commit que je veux garder est le premier (le d45cf43) je laisse donc pick.

Je ne veux pas garder les autres, je veux qu’ils soient fusionnés dans le commit que je veux garder. Je vais donc remplacer “pick” par “squash” (à noter qu’on pourrait mettre simplement “s”).

J’enregistre ensuite mes modifications, un autre fichier s’ouvre:

Si on enregistrait à ce stade, on aurait plus qu’un seul commit qui aurait pour message la concaténation de tous les messages des commits regroupés.

Ici, on va simplement les supprimer et écrire un message plus parlant.

On sauvegarde et c’est fini 🙂

Si on fait un git log, on voit bien un seul commit:

Il faut ensuite faire un push -f car on souhaite réécrire l’historique de la branche distante.

Après acceptation de la merge request on a:

Ici, on a un historique clair: un seul commit parlant est généré (en plus du commit de fusion).

Pour aller plus loin: https://git-scm.com/book/fr/v2/Utilitaires-Git-R%C3%A9%C3%A9crire-l%E2%80%99historiqu

2. Squasher via l’IDE

Il est également possible de Squasher des commits via votre IDE:

Suite Jetbrains:

Allez dans le menu Git puis cliquez sur Git log.

La liste des commits s’affiche en bas.

Faites un clic droit puis sélectionnez “squash commits”.

Entrez ensuite le message du commit souhaité:

Validez et c’est tout bon, voici le git log:

Ici, si on fait un git push -f et qu’on fusionne cette branche dans master, on obtient le même résultat que précédemment 😉 

Pour VSCode: https://dannyherran.com/2020/06/git-squash-commit-vs-code/ 

3. Squasher via l’interface Web

Avec Gitlab:

Cochez simplement l’option “Squash commits” dans votre Merge Request

Par défaut Gitlab Squash tous les commits de la branche en “Resolve “nom de l’issue associée””. Ce qui donne dans notre cas:

Je n’ai pas fait d’exemple sous Github mais le fonctionnement devrait être très proche.

Ici, on n’a pas le choix du nommage de notre commit et on a forcément un commit par issue ce qui n’est pas forcément top. En effet, parfois on aimerait avoir plusieurs commits par issue pour plus de clarté.

En revanche, si les issues sont assez petites ça peut faire l’affaire. Le gros point fort ici est sa facilité d’utilisation.

Bonus

Lors de mes premiers squash j’appréhendais énormément de le faire (notamment à cause du git push -f qui ne pardonne pas en cas d’erreur). Si c’est votre cas aussi, n’hésitez pas à créer une branche locale temporaire à partir de votre branche locale à squash!  Cela vous permettra d’avoir un backup en cas de problème et vous n’aurez qu’à supprimer cette branche une fois la merge request acceptée 😉

Ce que je faisais les premières fois:

git checkout ma_branche_a_squash

git branch ma_branch_backup

// je fais mon squash

// la MR est validée

git branch -d ma_branch_backup

Conclusion

Il est indispensable à mes yeux de garder un historique Git propre, c’est pourquoi j’espère qu’à travers cet article je vous aurais convaincu de Squasher vos commits et que vous avez à présent toutes les connaissances nécessaires pour le faire 🙂 

Sources

https://git-scm.com/book/fr/v2/Utilitaires-Git-R%C3%A9%C3%A9crire-l%E2%80%99historique

Image d’illustration: https://xkcd.com/1296/