Les petits plus : gitup

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.