Je ne suis pas enthousiasmé par l’annonce de Github. Ok, on peut faire désormais un squash sur une branche avant de lancer le merge.
Je n’aime pas généralement les squash et les rebase, c’est un fait, mais le cas de Github est probablement 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 republié la branche. Il est temps de fusionner votre code avec la branche principale.
Pourquoi diable chercher à faire un squash de la branche ? La seule raison qu’on m’a donné est « avoir un joli historique ». Plus basiquement ne pas avoir plein de commit en vrac quand on fait un git log
sur master.
Si votre outil de visualisation d’historique est mauvais, changez votre outil de visualisation, ne bidouillez pas l’historique à la source ! squash, rebase et fast-forward sont simplement de mauvaises pratiques de contournement, malheureusement trop répandues.
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 laisser les options par défaut. Vouloir réécrire l’histoire et effacer l’historique me semble une pratique plus que contestable pour juste contourner le problème.
Vous voulez ma pratique idéale ? Des branches pour tous les développements, 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 principale ne contient que des merge, toujours en –no-ff.
Pour l’historique, le plus souvent, on ne devrait même pas regarder les commit réalisé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ésultat c’est une visualisation linéaire, sans détail inutile, simple à lire, et qui ne nécessite jamais de tricher en supprimant ou modifiant l’historique réel.
Si vous avez besoin, l’historique complet existe toujours et peut être exploré. Il y a des outils ou paramètres qui permettent d’avoir une très bonne vision de l’arborescence quand vous en avez besoin.
C’est quand même dommage d’utiliser un outil de versionnement qui est excellent avec les branches et le travail en parallèle pour ensuite en faire une bouillie de commit linéaire et virtuels.
5 réponses à “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.
Carrément d’accord !
Une discussion en cours sur dev-platform à Mozilla sur le même type de sujet.
https://groups.google.com/forum/#!topic/mozilla.dev.platform/UViRHBGGFwo
« 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 ! »