Quand une équipe dépasse deux ou trois développeurs, la question du workflow Git devient inévitable. GitFlow et Trunk-Based Development (TBD) dominent le débat — et les partisans des deux camps sont rarement d’accord.
GitFlow : la rigueur au prix de la complexité
GitFlow structure le développement autour de branches longues : main, develop, des branches de feature, de release et de hotfix. Le principe est séduisant : chaque étape du cycle de vie a sa branche dédiée.
Ce qui fonctionne bien : les équipes qui livrent en versions numérotées (v1.2.3), les projets avec des cycles de release longs, les environnements où plusieurs versions majeures coexistent en production.
Ce qui coince : la complexité opérationnelle est réelle. Les conflits de merge s’accumulent sur les branches de feature qui vivent longtemps. La courbe d’apprentissage est plus steep qu’il n’y paraît.
Trunk-Based Development : la simplicité qui force la discipline
En TBD, tout le monde commit sur la branche principale (main ou trunk), idéalement plusieurs fois par jour. Les features incomplètes sont cachées derrière des feature flags, pas des branches séparées.
Ce qui fonctionne bien : les équipes qui déploient en continu, les organisations avec une forte culture CI/CD, les projets où l’intégration fréquente est un impératif.
Ce qui coince : TBD requiert une suite de tests solide et une culture de discipline élevée. Committer sur main avec des tests insuffisants, c’est casser la production.
Le tableau de décision
| Critère | GitFlow | Trunk-Based |
|---|---|---|
| Déploiements par semaine | < 5 | > 5 |
| Taille d’équipe | 5-20 | 2-50 |
| Gestion de versions multiples | ✓ | ✗ |
| Couverture de tests requise | Modérée | Élevée |
| Complexité Git | Élevée | Faible |
La vraie question n’est pas technique
Le choix entre GitFlow et TBD est moins une décision technique qu’une décision organisationnelle. Une équipe qui n’est pas prête culturellement à committer sur main plusieurs fois par jour ne bénéficiera pas de TBD — elle le subira.
Notre recommandation : si vous démarrez un nouveau projet avec une équipe jeune, commencez par TBD avec des feature flags. Si vous avez une base existante sous GitFlow et que ça fonctionne, la migration vers TBD n’est justifiée que si vous avez des problèmes d’intégration mesurables.
Variantes intermédiaires
GitHub Flow (branche courte + PR + merge direct sur main) est souvent le meilleur compromis pour les équipes de 3 à 15 personnes qui déploient en continu : moins complexe que GitFlow, moins exigeant que TBD pur.
La formation Git & GitFlow en équipe aborde ces trois approches avec des ateliers pratiques sur des scénarios réels.