Trunk-based ou GitFlow ? Choisir un flux de travail Git
Le choix d'un workflow Git influence toute la vélocité d'une équipe. Pourquoi le trunk-based development a largement supplanté GitFlow pour la livraison continue.
La façon dont une équipe organise ses branches Git n'est pas un détail cosmétique de « process » : elle conditionne la fréquence des livraisons, la douleur des fusions, la stabilité de la production et, au fond, la vélocité de toute l'équipe. Deux grandes philosophies s'opposent, et l'une a nettement pris l'ascendant — la recherche explique pourquoi.
GitFlow : structuré mais lourd
GitFlow, formalisé par Vincent Driessen en 2010, définit de nombreuses branches à durée de vie longue : main, develop, des branches release, hotfix, plus une branche par fonctionnalité. C'est rigoureux et adapté à des logiciels livrés par versions espacées (par exemple un logiciel installé chez des clients). Mais il a un défaut majeur en contexte web : les branches qui vivent longtemps divergent de la base, et leur fusion devient un cauchemar — le fameux « merge hell », où l'on passe plus de temps à résoudre des conflits qu'à produire de la valeur. Driessen lui-même a depuis précisé que GitFlow n'est pas adapté à la livraison continue.
Plus une branche vit longtemps, plus elle diverge, et plus sa fusion est douloureuse et risquée.
Trunk-based : simple et continu
Le trunk-based development mise sur une branche principale unique (le « trunk ») dans laquelle chacun intègre son travail très fréquemment — au moins une fois par jour — via de petites branches de très courte durée (quelques heures), immédiatement relues et fusionnées. C'est le socle naturel de l'intégration continue : en intégrant souvent, les conflits restent minuscules et les problèmes sont détectés tôt.
Comment livrer du code inachevé ?
La question évidente : comment intégrer plusieurs fois par jour sans casser la production avec du code en cours de développement ? La réponse tient en deux techniques complémentaires :
- Les feature flags (drapeaux de fonctionnalité) — on fusionne le code en production mais on l'active seulement quand il est prêt, pour tous ou pour un sous-ensemble d'utilisateurs.
- Le découpage en petits incréments cohérents — chaque changement est complet et non cassant, même s'il ne délivre qu'une fraction de la fonctionnalité finale.
Le verdict de l'industrie
Ce n'est pas qu'une question de goût : la recherche DORA associe statistiquement le trunk-based development à une meilleure performance de livraison (les équipes qui l'adoptent déploient plus souvent et plus sûrement). Pour la plupart des produits web et SaaS livrés en continu, c'est aujourd'hui le choix par défaut. GitFlow, lui, garde du sens pour des logiciels versionnés distribués à des clients qui installent des versions figées et doivent maintenir plusieurs versions en parallèle. Le bon workflow dépend donc de la façon dont vous livrez — mais si vous déployez en continu, le trunk-based gagne.