Catégories
git

Arrê­tez avec les git squash

Je ne suis pas enthou­siasmé par l’an­nonce de Github. Ok, on peut faire désor­mais un squash sur une branche avant de lancer le merge.

Je n’aime pas géné­ra­le­ment les squash et les rebase, c’est un fait, mais le cas de Github est proba­ble­ment le cas où le squash me semble toujours une mauvaise idée.

Cas d’usage : Vous avez fait une branche, envoyé plusieurs commit dessus, publié la branche pour que d’autres fassent une revue, peut-être corrigé un ou deux trucs et repu­blié la branche. Il est temps de fusion­ner votre code avec la branche prin­ci­pale.

Pourquoi diable cher­cher à faire un squash de la branche ? La seule raison qu’on m’a donné est « avoir un joli histo­rique ». Plus basique­ment ne pas avoir plein de commit en vrac quand on fait un git log sur master.

Si votre outil de visua­li­sa­tion d’his­to­rique est mauvais, chan­gez votre outil de visua­li­sa­tion, ne bidouillez pas l’his­to­rique à la source ! squash, rebase et fast-forward sont simple­ment de mauvaises pratiques de contour­ne­ment, malheu­reu­se­ment trop répan­dues.

Il est tout à fait possible de voir les choses sous la forme de branches et de ne pas être pollué par les commit unitaires des autres branches. Il y a plein de bons outils. En fait même git log est tout à fait viable, il suffit de ne pas lais­ser les options par défaut. Vouloir réécrire l’his­toire et effa­cer l’his­to­rique me semble une pratique plus que contes­table pour juste contour­ner le problème.

Vous voulez ma pratique idéale ? Des branches pour tous les déve­lop­pe­ments, même les fix unitaires. Jamais(*) de fast-forward, de squash ou de rebase une fois le code publié (chez vous vous faites bien ce que vous voulez). La branche prin­ci­pale ne contient que des merge, toujours en –no-ff.

Pour l’his­to­rique, le plus souvent, on ne devrait même pas regar­der les commit réali­sés sur d’autres branches que celle en cours – le commit de merge qui résume ce qui a été fait devrait suffire.

Le résul­tat c’est une visua­li­sa­tion linéaire, sans détail inutile, simple à lire, et qui ne néces­site jamais de tricher en suppri­mant ou modi­fiant l’his­to­rique réel.

Si vous avez besoin, l’his­to­rique complet existe toujours et peut être exploré. Il y a des outils ou para­mètres qui permettent d’avoir une très bonne vision de l’ar­bo­res­cence quand vous en avez besoin.

C’est quand même dommage d’uti­li­ser un outil de version­ne­ment qui est excellent avec les branches et le travail en paral­lèle pour ensuite en faire une bouillie de commit linéaire et virtuels.

5 réponses sur « Arrê­tez avec les git squash »

Hum… je ne suis pas vraiment d’accord.

> faire une bouillie de commit linéaire et virtuels.

Et pourtant, ne pas se soucier de l’historique crée en général une bouillie de commits souvent illisibles et pouvant poser de vrais gros problèmes le jour où une régression existe et n’est pas détectée par des processus d’intégration continue ou autre (ce n’est pas toujours possible).

Avoir un joli historique est en général le signe d’un soucis de qualité. Et pour avoir déjà réussi à passer de l’ordre de 2 jours à naviguer dans un historique absolument illisible à la recherche d’un commit provoquant une régression, j’ai du mal à me dire que c’est juste un problème d’usage d’outil de visualisation.

Si on est capable d’avoir CI + octopus merge alors ça peut en effet être intéressant et je suis d’accord que dans ce cas on peut oublier squash/rebase.

En exemple voici ce que j’avais mis en place comme workflow, justement à base de rebase avant merge (le squash avait été évoqué même si on ne l’a pas mis en place) : http://blog.sogilis.com/post/104148375576/notre-workflow-git-pourquoi-comment

le squash ou rebase peut être utile quand tu travailles sur un projet opensource avec des niveaux de compétence très variables. Les messages mal formatés, les commits faisant-défaisant-refaisant après de nombreuses revues. Il est souvent plus encourageant pour un débutant d’accepter sa branche un peu funky, et de corriger dans un rebase tout en lui enseignant ce qu’il faut corriger la prochaine fois dans son style de commit.

« Si votre outil de visualisation d’historique est mauvais, changez votre outil de visualisation, ne bidouillez pas l’historique à la source ! »

Je suis d’accord avec le contenu de l’article, et cette phrase résume de façon générale les problèmes qu’on a à l’IT… Très souvent des principes ou des méthodes sont remis en cause parce que « çà ne marche pas dans mon outil »… « et bien change d’outil ! »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *