GitHub Flow vs GitFlow vs Trunk-based development
Résumé : il existe trois workflows Git dominants en 2026, chacun adapté à un contexte différent. GitHub Flow est simple et moderne, adapté aux applications web. GitFlow est structuré, adapté aux logiciels avec versions numérotées. Trunk-based development est ultra-rapide, adapté à l'intégration continue à grande échelle. Cette leçon les compare honnêtement, sans propagande.
1. Pourquoi trois workflows différents ?
Un workflow Git est la façon dont une équipe organise ses branches — quelles branches existent, à quoi elles servent, comment elles fusionnent. Il n'y a pas de « meilleur » workflow dans l'absolu : chacun optimise pour un contexte.
2. GitHub Flow — le workflow moderne par défaut
C'est le plus simple et le plus utilisé en 2026 pour les applications web. Popularisé par GitHub eux-mêmes vers 2011.
Règles GitHub Flow :
- Une seule branche principale :
main. - Toute nouvelle chose part d'une branche de fonctionnalité issue de
main. - Une pull request est ouverte dès qu'il y a du code à discuter.
- Une fois la PR fusionnée, la branche est supprimée.
mainest toujours prête à être déployée — souvent, la fusion déclenche même le déploiement automatiquement.
Avantages :
- Simple à comprendre pour un nouveau membre de l'équipe.
- Compatible avec le déploiement continu (chaque merge = un déploiement).
- Peu de branches ouvertes en même temps, l'esprit reste clair.
Inconvénients :
- Ne gère pas nativement les versions numérotées (v1.0, v1.1, v2.0).
- Nécessite une suite de tests automatisée solide — sinon, un merge peut casser la prod.
À privilégier si : vous développez une application web déployée en continu (SaaS, site marchand, app mobile).
3. GitFlow — le workflow structuré des logiciels versionnés
Formalisé par Vincent Driessen en 2010, GitFlow a été très populaire dans les années 2010 avant d'être supplanté par GitHub Flow pour le web. Il reste pertinent dans certains contextes.
Les cinq types de branches GitFlow :
| Branche | Rôle |
|---|---|
main | Historique des versions officielles publiées (chaque commit correspond à une release) |
develop | Intégration continue des fonctionnalités terminées |
feature/* | Développement d'une nouvelle fonctionnalité, dérivée de develop |
release/* | Stabilisation d'une future version (correction de bugs, pas de nouvelles fonctionnalités) |
hotfix/* | Correction urgente d'un bug critique en production |
Avantages :
- Support parfait des versions numérotées — chaque release est clairement séparée.
- Séparation claire entre développement en cours et code stable.
- Gestion propre des correctifs urgents en parallèle du développement.
Inconvénients :
- Complexe : 5 types de branches, des règles de fusion strictes.
- Lent : les fonctionnalités attendent parfois plusieurs jours avant d'atterrir en production.
- Overkill pour un site web moderne où on déploie 50 fois par jour.
À privilégier si : vous développez un logiciel installable (application desktop, driver, plugin, firmware) avec des versions numérotées que les clients installent explicitement.
4. Trunk-based development — la vitesse maximale
C'est le workflow des grandes équipes qui font du CI/CD à grande échelle — Google, Meta, LinkedIn, Uber. Popularisé par le livre Accelerate de Nicole Forsgren.
Les principes du Trunk-based :
- Une seule branche à long terme (
trunkoumain). - Les branches de fonctionnalité sont très courtes — moins de 24 heures avant fusion.
- Le code inachevé est déployé quand même, mais masqué par un feature flag (interrupteur activable en production).
- Aucune branche
developnirelease— tout est dans le tronc. - Nécessite une suite de tests automatiques massive (des centaines de milliers de tests) et une culture d'intégration continue.
Avantages :
- Vitesse maximale : le code atteint la production en quelques heures, pas en semaines.
- Aucun conflit de fusion significatif : les branches sont trop courtes pour diverger.
- Retour utilisateur ultra-rapide : on déploie et on ajuste.
Inconvénients :
- Exige une discipline énorme : suite de tests exhaustive, feature flags partout, culture DevOps mature.
- Peu adapté aux petites équipes ou aux projets non testés.
- Nécessite des outils avancés de gestion de feature flags (LaunchDarkly, Unleash, Split).
À privilégier si : vous êtes dans une grande équipe avec une culture d'ingénierie forte, ou dans un contexte de haute vélocité (Facebook déploie ~2 fois par jour, Amazon ~50 fois par jour).
5. Tableau comparatif complet
| Critère | GitHub Flow | GitFlow | Trunk-based |
|---|---|---|---|
| Complexité | Faible | Élevée | Moyenne |
| Branches principales | 1 (main) | 2 (main + develop) | 1 (trunk) |
| Durée de vie des feature branches | 1 à 5 jours | 1 à 4 semaines | Moins de 24 heures |
| Fréquence de déploiement | Plusieurs par jour | Toutes les 2 à 8 semaines | Plusieurs par jour |
| Adapté aux versions numérotées | Non | Oui, très bien | Non, avec feature flags |
| Prérequis techniques | CI/CD basique | Aucun spécifique | CI/CD très mature, feature flags |
| Taille d'équipe idéale | 2 à 30 personnes | 5 à 50 personnes | 50+ personnes |
| Type de projet idéal | Web SaaS, application mobile | Logiciel installable, plugin, firmware | Grosse plateforme SaaS ou monorepo |
6. Notre recommandation en 2026
Pour 95 % des équipes qui débutent un projet aujourd'hui, le bon choix est GitHub Flow. Voici pourquoi.
GitFlow n'est pertinent que si vous avez de vraies versions numérotées à maintenir chez les clients (logiciel desktop, driver, plugin, système embarqué). En 2026, ces cas deviennent minoritaires face à l'essor du SaaS.
Trunk-based est réservé à des équipes avec une culture d'ingénierie très mûre. Le mettre en place trop tôt, sans les tests et sans les feature flags, cause plus de problèmes qu'il n'en résout.
Retenir en 30 secondes
- GitHub Flow : une seule branche
main, feature branches courtes, PR, fusion, déploiement. Recommandé par défaut. - GitFlow :
main+develop+ feature + release + hotfix. Adapté aux logiciels avec versions numérotées. - Trunk-based : une seule branche, branches très courtes, feature flags. Adapté aux grosses équipes matures en CI/CD.
- 95 % des équipes web modernes utilisent GitHub Flow ou une variante.
Suivant : Résoudre un conflit de fusion →