Catégories
git

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.

Catégories
Développement informatique git

Mention bot, cibler la revue de code

À La Ruche qui Dit Oui, comme dans mon équipe précé­dente, on fait des revues de code avec la règle des deux pouces. Pour qu’une modi­fi­ca­tion appli­ca­tive passe en produc­tion il faut qu’elle soit vali­dée par deux pairs, qui vont mettre un ? (le feed­back par emoji, si vous n’avez pas essayé, vous manquez quelque chose).

En discu­tant avec les équipes d’Al­go­lia, on m’a pointé mention-bot. L’idée est simple : avec un git blame on repère qui est le déve­lop­peur qui a le plus travaillé sur ces parties de code et on le mentionne expli­ci­te­ment auto­ma­tique­ment comme parti­ci­pant poten­tiel à la revue.

Do you have a GitHub project that is too big for people to subscribe to all the noti­fi­ca­tions? The mention bot will auto­ma­ti­cally mention poten­tial revie­wers on pull requests. It helps getting faster turna­round on pull requests by invol­ving the right people early on.

Je ne sais pas si ça va vrai­ment s’in­té­grer à notre struc­tu­ra­tion par équipes ici (le déve­lop­peur ciblé risque d’être sur un autre équipe, donc pas la meilleure personne pour faire la revue sur le projet en cours) mais je partage quand même.

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.

Catégories
git

Bash­git prompt

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.

gitprompt

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.

Catégories
git

Quelques outils pour simpli­fier github

Pour mes propres archives, et pour ceux qui ne connaissent pas encore, github met à dispo­si­tion deux outils pour simpli­fier les inter­ac­tions :

Le premier c’est github pour mac, une inter­face graphique simpliste mais effi­cace pour gérer les dépôts, commit et branches. Ça ne fait pas le café mais ça fait la base utile pour ceux qui ont une utili­sa­tion naive. Le bonus ce sont les noti­fi­ca­tions d’ac­ti­vité qui passent alors dans le système d’alerte inté­gré d’OS X.

Le second c’est hub, un rempla­ce­ment de la commande git pour les adeptes de la ligne de commande. On ajoute simple­ment quelques simpli­fi­ca­tions de commandes. Rien d’in­dis­pen­sable, mais de quoi éviter de réflé­chir quand on bosse avec github : utili­ser les couples utili­sa­teur/projet dans la ligne de commande, créer une branche à partir d’une pull request, initier un fork, lancer une pull request, etc.

Côté alertes pour les diffé­rents commits d’un projet, il y a aussi Commit­ted (pour Mac OS X là aussi)

Naho­lyr a aussi un petit script pour gérer les pull request, en surcouche à hub.