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.
Laisser un commentaire