Catégorie : git

J’ai toujours été gêné par l’in­té­gra­tion de grosses modi­fi­ca­tions dans git.

Dans l’idéal on fait une série de modi­fi­ca­tions auto­nomes, on les soumet à la revue des pairs puis on les intègre dans les branche prin­ci­pale qui peut partir en produc­tion à tout moment.

Ça c’est la théo­rie. En pratique je fais des erreurs que je ne vois qu’à la fin des modi­fi­ca­tions. Mes collègues auront de toutes façons des retours sur ce que j’ai poussé en ligne et me deman­de­ront des modi­fi­ca­tions avant l’in­té­gra­tion finale. Si ce n’est pas le cas au moins une fois sur deux, c’est que nous travaillons mal.

Et là… les ennuis commencent.

Mes modi­fi­ca­tions ne sont plus auto­nomes. J’ai des correc­tifs à la fin. Poten­tiel­le­ment mes modi­fi­ca­tions précé­dentes sont donc incom­plètes, de mauvaise qualité ou même défaillantes. Si j’in­tègre mon code à la fin de la revue, je casse toute la belle théo­rie.

J’ai vu deux pratiques suivant les équipes :

La première pratique c’est d’in­té­grer le code tel quel sur la branche master. C’est ce qui m’ap­pa­rait le plus cohé­rent. Le code de la branche est poten­tiel­le­ment instable mais tous les points d’étape de master sont de qualité. Pour parcou­rir les modi­fi­ca­tions de la branche master on ajoute --merges --first-parent histoire de ne pas voir les modi­fi­ca­tions internes des sous-branches. Ni vu, ni connu mais le débo­gage de la branche après coup en cas de besoin ne sera pas idéal.

L’al­ter­na­tive est de fusion­ner en une seule toutes les modi­fi­ca­tions de la branche lors de son inté­gra­tion. On perd toute la granu­la­rité et ça peut rendre bien plus diffi­cile de tracer l’ori­gine d’une anoma­lie par la suite, ou de comprendre le pourquoi et le comment d’un chan­ge­ment. C’est encore viable sur 100 voire 200 lignes bien grou­pées mais ça devient fran­che­ment liti­gieux au delà.

La seule pratique que je réprouve tota­le­ment est celle du rebase sans squash. On importe tous les chan­ge­ments direc­te­ment sur master et on perd tota­le­ment la capa­cité d’avoir un master stable. Ne faites pas ça.

La troi­sième voie c’est la réécri­ture de l’his­to­rique.

En théo­rie c’est mal, au moins pour les branches déjà publiées. En pratique tant qu’au­cun autre code ne se base dessus, ça ne pose pas vrai­ment de problèmes. Sur des équipes en entre­prise ça se maitrise assez bien. Sur du code open source ça me semble plus liti­gieux. Github le gère parfai­te­ment dans les pull-request en cours de revue.

Les vrais, les purs, le font en ligne de commande. Je suis admi­ra­tif devant ceux qui savent décou­per une modi­fi­ca­tion ou ajou­ter un correc­tif dix chan­ge­ments en arrière dans l’his­to­rique sans réflé­chir ni tout casser. Tech­nique­ment ça ne pose pas vrai­ment de diffi­cul­tés mais c’est long, propice aux erreurs, et le moindre faux pas peut faire de gros dégâts irré­mé­diables. Je ne trouve pas les inter­faces graphiques inutiles pour tout ça.

Et là, merci Patrick, gitup vient désor­mais à ma rescousse. L’in­ter­face est simpliste, pas toujours pratique, mais elle fait ce que je n’ai pas vu ailleurs.

• Je suis capable de sépa­rer un chan­ge­ment en deux quelle que soit sa posi­tion dans l’his­to­rique ;
• Je suis capable de dépla­cer un chan­ge­ment en haut ou en bas dans l’his­to­rique d’un simple raccourci clavier ;
• Je suis capable de faire un correc­tif, le descendre dans l’his­to­rique, puis le fusion­ner avec le chan­ge­ment initial qu’il faut corri­ger.

Tout ça graphique­ment, avec la possi­bi­lité de reve­nir en arrière quand je veux si jamais je fais des bêtises.

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.

Je bave souvent devant les prompt de termi­nal qu’on voit sur le web mais une fois installé ça fait très gadget, plus gênant qu’autre chose.

J’ai tout de même ajouté un peu de couleur, pour aider à repé­rer le début de chaque invite quand je remonte dans l’his­to­rique.

Reste que quelques indi­ca­teurs ça peut être utile dans un réper­toire git. J’ai tenté oh-my-git mais fina­le­ment je me suis fixé sur bash-git-prompt, avec quelques icônes simples à comprendre. Je regrette juste le nombre de couleurs trop élevé mais ça doit se confi­gu­rer.