Rebase pour rafraîchir ta branche

Je fais partie de plusieurs équipes logicielles et, très souvent, on commite du code sur notre branche principale. Point commun de mes équipes : pas de branche develop, pas de cycles de release. On livre régulièrement, c’est tout.

Ce n’est pas la pratique courante dans une grande entreprise, mais dans les sociétés agiles centrées sur le logiciel, c’est assez banal.

La question, c’est comment faire ça sans se marcher sur les pieds.

Git

Tout tient à git et à l’agilité. L’outil qui gère le code source, et un petit bout de la mentalité de notre gestion de projet.

Git, c’est juste un moyen de détecter les différences entre des copies. Si la copie de production contient A, que Joe travaille sur B et Sally sur C, Git sait calculer les différences et fusionner les copies sans conflit.

Le plus délicat, c’est quand le travail dure longtemps et que les contributions arrivent à des rythmes différents.

C’est là que rebase entre en jeu. git rebase origin/main garantit que mon travail, celui qui part de main, est à jour de tout ce que mes collègues ont apporté. C’est la bonne chose à faire et ça évite du retravail quand des conflits surgissent. Ça assure que mon travail est à jour avant d’être fusionné dans la branche main. La source de vérité.

Flow

Beaucoup d’équipes suivent git-flow. Atlassian le décrit très bien, pas besoin d’en dire plus.

Mais je ne le trouve pas parfait.

En ingénierie logicielle, on a tendance à automatiser les processus qu’on chérit, pour être plus productifs. Ça marche bien, mais ça a ses propres défauts.

Par exemple, une branche de fonctionnalité est un bon moyen de tester une fonctionnalité précise. Chaque commit peut donc déclencher un quasi-déploiement pour montrer le potentiel d’une nouveauté.

Le résultat imparfait, c’est que la branche de fonctionnalité déclenche un processus automatique pour déployer cette démo.

C’est à la fois coûteux et insuffisant.

Branches de travail

Dans mon équipe, j’adopte une approche simple : les branches work/*. Même idée que les branches de fonctionnalité, mais dans un espace de noms à part pour échapper aux processus automatiques.

Les branches de travail portent le préfixe work/ et sont explicitement exclues des pipelines automatisés. Elles sont pensées comme la « sauvegarde automatique » du monde du contrôle de version.

J’encourage activement mes équipes à travailler surtout dans leur branche work/*, et à ne fusionner dans leur branche feature/* que quand elles veulent qu’un pipeline tourne.

Pour finir

Je précise que je ne pratique ça dans mes équipes que depuis peu. Malgré l’effort en plus pour distinguer feature/* de work/*, ça a l’air de bien marcher.

Je reconnais que les étapes de blocage sont aussi un bon moyen d’éviter des déploiements et des builds inutiles. Ce sont d’excellentes façons d’arriver à un résultat proche, mais elles ne sont malheureusement pas disponibles dans les environnements où je travaille.

J’ai toujours envie d’avoir des retours, et peut-être des idées de nouvelles façons de travailler. Si tu en as, écris-moi.