Le trunk based development est un modèle de gestion de branches où toute l'équipe intègre son travail sur une seule branche commune, plusieurs fois par jour, via des branches éphémères qui vivent moins d'une journée. Cette page explique ce modèle sans jargon, le compare aux autres stratégies de branching (GitFlow, GitHub Flow, GitLab Flow, Release Flow, OneFlow), et montre pourquoi il conditionne l'intégration continue et la livraison continue. Elle s'adresse aux équipes qui hésitent entre plusieurs conventions de branches et veulent choisir en connaissance de cause, chiffres DORA à l'appui.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Définir le trunk based development et le rôle des branches éphémères
- Utiliser des feature flags pour livrer du code incomplet sans casser la production
- Comparer GitFlow, GitHub Flow, GitLab Flow, Release Flow et OneFlow
- Choisir un modèle adapté à la taille de votre équipe et à votre cadence de déploiement
- Adopter le trunk based en pratique et désamorcer les objections classiques
Qu'est-ce que le Trunk-Based Development
Section intitulée « Qu'est-ce que le Trunk-Based Development »Le trunk based development (développement basé sur le tronc) désigne une stratégie de branching où les développeurs collaborent sur une branche unique appelée trunk (souvent nommée main), en résistant à la tentation de créer des branches de développement qui durent. C'est la définition portée par le site de référence trunkbaseddevelopment.com, maintenu par Paul Hammant. L'idée centrale tient en une phrase : intégrer tôt et souvent plutôt que d'accumuler du code isolé pendant des semaines.
Ce modèle s'oppose frontalement aux approches où chaque fonctionnalité vit dans sa propre branche pendant des jours ou des semaines avant une fusion douloureuse. Prenons une équipe de six développeurs sur une API de facturation. En trunk based, chacun pousse son travail vers main au moins une fois par jour ; les conflits restent minuscules parce qu'ils portent sur quelques heures d'écart, pas sur trois semaines de divergence.
Une seule branche vivante, branches éphémères (< 1 jour), commits fréquents
Section intitulée « Une seule branche vivante, branches éphémères (< 1 jour), commits fréquents »Le principe fondateur est qu'il n'existe qu'une seule branche longue durée : le trunk. Tout le reste est jetable. Sur une petite équipe, les développeurs peuvent même committer directement sur le trunk plusieurs fois par jour. Sur une équipe plus grande (le scaled trunk based development), on utilise de courtes branches éphémères (short-lived branches) : elles servent uniquement à la revue de code et à la vérification par l'intégration continue avant que le code n'atterrisse sur le trunk.
La règle de durée est explicite : une branche éphémère doit vivre moins d'un jour et fusionner dans le trunk au maximum toutes les 24 heures. Concrètement, un développeur qui ajoute un endpoint de remboursement crée une branche le matin, ouvre une Pull Request après deux ou trois commits, la fait valider par la CI et un collègue, puis la fusionne dans l'après-midi. La branche disparaît le jour même. On évite ainsi le merge hell, ce moment où fusionner une vieille branche demande de résoudre des dizaines de conflits accumulés.
Le rôle des feature flags pour intégrer du code incomplet sans casser la prod
Section intitulée « Le rôle des feature flags pour intégrer du code incomplet sans casser la prod »La première objection au trunk based est évidente : comment fusionner une fonctionnalité à moitié terminée sans casser la production ? La réponse s'appelle le feature flag (drapeau de fonctionnalité, aussi nommé feature toggle). Un feature flag est un interrupteur logiciel qui active ou désactive un morceau de code sans redéployer l'application. On intègre le code sur le trunk, mais il reste éteint tant qu'il n'est pas complet.
Reprenons l'API de facturation. Vous développez un nouveau moteur de calcul de TVA sur plusieurs jours. Chaque bout de code part sur le trunk, mais entouré d'une condition du type if (featureFlags.nouveauCalculTVA). Comme le drapeau est à false en production, les utilisateurs ne voient rien. Le jour où le moteur est prêt et testé, vous basculez le flag à true, progressivement, pour un pourcentage d'utilisateurs. Le code était déjà en production depuis longtemps, seule son activation change. Cette technique, combinée au branch by abstraction (introduire une couche d'abstraction pour remplacer un composant en douceur), rend possible l'intégration continue sans branches longues.
Pourquoi c'est un prérequis de l'intégration continue (lien DORA, équipes élites)
Section intitulée « Pourquoi c'est un prérequis de l'intégration continue (lien DORA, équipes élites) »Le trunk based n'est pas une préférence esthétique : c'est la condition technique de l'intégration continue. La définition rigoureuse de la CI, portée par les recherches DORA (DevOps Research and Assessment, le programme de recherche derrière le rapport State of DevOps), est précise : la CI, c'est pratiquer le trunk based development et maintenir une suite de tests automatisés rapides qui s'exécutent après chaque commit sur le trunk. Sans tronc commun régulièrement mis à jour, il n'y a rien à intégrer en continu.
Les chiffres du programme DORA sont sans ambiguïté. Les équipes élite qui atteignent leurs objectifs de fiabilité sont 2,3 fois plus susceptibles de pratiquer le trunk based development, et 5,8 fois plus susceptibles de s'appuyer sur l'intégration continue. Le trunk based alimente directement les métriques DORA : plus les branches sont courtes, plus la fréquence de déploiement monte et plus le délai de livraison baisse. C'est le socle sur lequel repose ensuite la livraison continue, puis le déploiement continu.
Les modèles de branches comparés
Section intitulée « Les modèles de branches comparés »
Il n'existe pas de modèle universel. Le bon choix dépend de votre cadence de déploiement, de la taille de l'équipe et de la nécessité ou non de maintenir plusieurs versions en parallèle. Cette section détaille les grands modèles, du plus lourd au plus léger, pour situer le trunk based dans le paysage. Pour la mise en œuvre côté outil Git, la page workflows Git complète cette lecture stratégique.
GitFlow (Vincent Driessen) : master/develop/feature/release/hotfix, et pourquoi il freine le déploiement continu
Section intitulée « GitFlow (Vincent Driessen) : master/develop/feature/release/hotfix, et pourquoi il freine le déploiement continu »GitFlow est le modèle publié par Vincent Driessen en 2010 dans l'article A successful Git branching model. Il repose sur deux branches permanentes, master (l'état en production) et develop (l'intégration en cours), et trois familles de branches de support : les branches feature (une par fonctionnalité, issues de develop), les branches release (préparation d'une version) et les branches hotfix (correctifs urgents partant de master). C'est un modèle riche et cadré, pensé pour du logiciel explicitement versionné.
Le problème, c'est justement sa richesse. Avec des branches feature qui peuvent vivre longtemps et un aller-retour develop vers release vers master, GitFlow multiplie les branches longue durée et les étapes manuelles. Il freine mécaniquement le déploiement continu. Driessen lui-même a ajouté en 2020 une note en tête de son article : si votre équipe fait de la livraison continue, adoptez un workflow beaucoup plus simple. Il précise que GitFlow reste pertinent pour du logiciel dont on maintient plusieurs versions dans la nature (une bibliothèque, un outil installé chez des clients), mais pas pour une application web déployée en continu.
GitHub Flow : main + branches de feature courtes + Pull Request + déploiement depuis main
Section intitulée « GitHub Flow : main + branches de feature courtes + Pull Request + déploiement depuis main »GitHub Flow est une simplification radicale. Une seule branche permanente, main, toujours déployable. Pour toute modification, on crée une branche de feature courte, on ouvre une Pull Request, on la fait relire, on la fusionne dans main, puis on déploie depuis main. Il n'y a ni branche develop, ni branche release. C'est le modèle que Driessen recommande implicitement quand il parle de workflow simple.
GitHub Flow est très proche du trunk based, avec une nuance : les branches de feature peuvent y vivre un peu plus longtemps que la limite stricte de 24 heures du trunk based. Pour une équipe qui livre une application SaaS plusieurs fois par semaine, GitHub Flow est souvent le point d'entrée idéal : peu de cérémonie, une PR par changement, un déploiement depuis main.
GitLab Flow : GitHub Flow + branches d'environnement (pré-prod, prod) ou de release
Section intitulée « GitLab Flow : GitHub Flow + branches d'environnement (pré-prod, prod) ou de release »GitLab Flow part de GitHub Flow et ajoute une notion absente : les branches d'environnement. La différence majeure entre les deux, c'est que GitLab Flow introduit des branches comme pre-production et production. Le code circule de main vers pre-production, puis de pre-production vers production, ce qui matérialise le passage par des environnements successifs avant d'atteindre les utilisateurs.
Ce modèle répond à un cas concret : toutes les équipes ne peuvent pas déployer en production à chaque fusion sur main. Une plateforme bancaire qui exige une validation en recette avant la mise en production trouvera dans les branches d'environnement une représentation fidèle de son processus. GitLab Flow autorise aussi, en option, des branches de release pour les projets versionnés, avec la règle de n'y porter que des corrections majeures. Cette logique de promotion se rapproche des approches GitOps, où l'état souhaité de chaque environnement est décrit dans Git.
Release Flow (Microsoft) : trunk-based avec branches de release en lecture
Section intitulée « Release Flow (Microsoft) : trunk-based avec branches de release en lecture »Release Flow est la variante de trunk based utilisée par les équipes de Microsoft (notamment Azure DevOps), décrite sur le blog DevOps de Microsoft. Le quotidien est purement trunk based : pour corriger un bug ou ajouter une fonctionnalité, on crée une topic branch courte depuis la branche d'intégration principale, on ouvre une Pull Request, elle passe les politiques de build et la revue, puis fusionne dans le trunk. Travailler depuis une seule branche principale élimine quasiment la dette de fusion.
La spécificité tient à la release. À la fin de chaque sprint, l'équipe crée une branche de release figée, par exemple releases/M129. Cette branche sert de photographie de la version livrée ; on n'y développe pas. Les correctifs urgents sont d'abord fusionnés sur le trunk, puis cherry-pickés (report sélectif d'un commit précis) vers la branche de release concernée. On combine ainsi la vitesse du trunk based et la traçabilité de versions figées pour un produit déployé à grande échelle.
OneFlow : alternative allégée à GitFlow
Section intitulée « OneFlow : alternative allégée à GitFlow »OneFlow, proposé par Adam Ruka en 2017, se présente comme une alternative simplifiée à GitFlow sans rien perdre de son expressivité. Sa prémisse : conserver une seule branche éternelle dans le dépôt, au lieu du couple master plus develop de GitFlow. Les cas avancés (retrouver une version passée, gérer un correctif sur une ancienne release) sont couverts par les tags Git plutôt que par des branches permanentes supplémentaires.
OneFlow autorise les mêmes branches de support que GitFlow (feature, release, hotfix), mais insiste sur leur caractère court et jetable : elles servent surtout à partager du code et à servir de sauvegarde. Pour une équipe attachée au cadre de GitFlow mais lassée de la complexité de deux branches permanentes, OneFlow offre un compromis : moins de branches longues, un schéma de versionnage plus simple, tout en restant loin de la discipline stricte du trunk based.
Forking Workflow : le modèle de l'open source
Section intitulée « Forking Workflow : le modèle de l'open source »Le Forking Workflow est la stratégie des projets open source hébergés sur des plateformes comme GitHub ou GitLab. Ici, chaque contributeur ne pousse pas sur le dépôt central : il en crée une copie personnelle (un fork), travaille dessus, puis propose ses changements au projet d'origine via une Pull Request entre dépôts. Le mainteneur du projet garde ainsi un contrôle total sur ce qui entre dans le dépôt officiel.
Ce modèle brille quand des contributeurs non fiables ou externes doivent pouvoir proposer du code sans avoir de droit d'écriture sur le dépôt principal. Un projet comme le noyau Linux ou une bibliothèque npm populaire reçoit des centaines de contributions d'inconnus : le fork est la barrière naturelle. En entreprise, sur une équipe soudée avec droit d'écriture partagé, ce niveau d'isolement est généralement superflu et ralentit le rythme.
Ship / Show / Ask : quand merger direct, ouvrir une PR pour info, ou demander une revue
Section intitulée « Ship / Show / Ask : quand merger direct, ouvrir une PR pour info, ou demander une revue »Ship / Show / Ask est une stratégie formulée par Rouan Wilsenach, publiée sur le site de Martin Fowler. Elle ne remplace pas les modèles précédents : elle répond à une question tactique du trunk based, faut-il une revue pour ce changement précis ? Elle classe chaque modification en trois catégories selon le niveau de contrôle nécessaire.
En mode Ship, on fusionne directement sur la branche principale sans revue : c'est l'esprit pur de l'intégration continue, réservé aux changements à faible risque (correction de faute, ajustement de log). En mode Show, on ouvre une Pull Request puis on la fusionne immédiatement, sans attendre de retour humain, pour rendre le changement visible et discutable a posteriori. En mode Ask, on ouvre une PR et on attend un retour avant de fusionner, pour les changements incertains ou structurants. Cette gradation évite le piège de la revue systématique qui ralentit tout, y compris les changements triviaux.
Tableau comparatif
Section intitulée « Tableau comparatif »Ce tableau résume les modèles selon quatre critères décisifs. La durée de vie des branches est le meilleur prédicteur de compatibilité avec la livraison continue : plus elle est courte, plus le modèle est adapté à un déploiement fréquent. Lisez-le comme une aide au choix, pas comme un classement de qualité : chaque modèle a son terrain.
| Modèle | Durée de vie des branches | Adapté au CD | Taille d'équipe | Complexité |
|---|---|---|---|---|
| Trunk-Based Development | < 1 jour | Excellent | Toute taille | Faible mais discipline forte |
| GitHub Flow | Quelques jours | Très bon | Petite à moyenne | Faible |
| GitLab Flow | Quelques jours + environnements | Très bon | Moyenne à grande | Moyenne |
| Release Flow | < 1 jour + releases figées | Très bon | Grande | Moyenne |
| OneFlow | Jours à semaines | Moyen | Moyenne | Moyenne |
| GitFlow | Semaines | Faible | Moyenne à grande, produit versionné | Élevée |
| Forking Workflow | Variable | Moyen | Open source, contributeurs externes | Moyenne |
Adopter le trunk-based en pratique
Section intitulée « Adopter le trunk-based en pratique »Passer au trunk based ne se décrète pas : c'est un ensemble de pratiques techniques qui se renforcent. Sans elles, intégrer plusieurs fois par jour devient dangereux. La bascule réussit quand les garde-fous automatisés sont en place avant de raccourcir les branches, pas après.
-
Revue continue et branches courtes. Adoptez des Pull Requests de petite taille, relues en quelques heures. Une PR de 40 lignes se relit ; une PR de 2000 lignes se survole. Ship / Show / Ask aide à calibrer le niveau de revue par changement.
-
CI rapide. La suite de tests doit tourner en quelques minutes, sinon personne n'intègre plusieurs fois par jour. Une CI de 45 minutes tue le trunk based. Parallélisez, mettez en cache, découpez les étapes.
-
Tests automatisés fiables. Chaque commit sur le trunk déclenche des tests automatisés qui garantissent que le système fonctionne toujours. Sans filet de tests, intégrer souvent revient à casser souvent.
-
Feature flags. Équipez-vous d'un système de feature flags pour livrer du code incomplet, activer progressivement et désactiver en cas d'incident sans redéployer.
Une fois ces fondations posées, le trunk based devient un accélérateur naturel. Il s'accorde avec les stratégies de déploiement progressif comme les rolling updates et rollbacks sous Kubernetes, où l'on active une nouvelle version par vagues et où l'on revient en arrière sans drame si un feature flag ou une métrique dérape.
Pièges et objections courantes
Section intitulée « Pièges et objections courantes »L'objection la plus fréquente concerne la revue de code : si on intègre plusieurs fois par jour, ne sacrifie-t-on pas la relecture ? Non. Le trunk based ne supprime pas la revue, il la raccourcit et la déplace. Les branches éphémères passent en Pull Request, mais la petite taille des changements rend la revue rapide. Ship / Show / Ask permet même de moduler : revue systématique pour le code sensible, intégration directe pour le trivial.
La deuxième crainte porte sur la qualité. Intégrer vite ferait-il baisser la qualité ? Les données DORA disent l'inverse : les équipes en trunk based ont un taux d'échec des changements plus bas, parce que les petits lots sont plus faciles à tester, à comprendre et à annuler. Un changement de 30 lignes qui casse la production se diagnostique en minutes ; une fusion de trois semaines qui casse la production se diagnostique en jours.
La troisième objection vise les équipes distribuées sur plusieurs fuseaux horaires. La réponse est double : d'abord une documentation solide, car les recherches DORA montrent que le trunk based contribue bien davantage à la performance quand la documentation est bonne ; ensuite les feature flags, qui découplent l'intégration du code de son activation, ce qui réduit le besoin de coordination synchrone entre continents.
À retenir
Section intitulée « À retenir »- Le trunk based development repose sur une seule branche vivante et des branches éphémères de moins d'un jour.
- Les feature flags permettent d'intégrer du code incomplet sans jamais casser la production.
- C'est le prérequis technique de l'intégration continue : pas de trunk commun, pas de CI réelle.
- Les équipes élite DORA sont 2,3 fois plus susceptibles de le pratiquer et maintiennent 3 branches actives ou moins.
- GitFlow convient au logiciel versionné mais freine le déploiement continu ; son auteur recommande un modèle plus simple pour la livraison continue.
- GitHub Flow et GitLab Flow sont des points d'entrée accessibles ; Release Flow et OneFlow répondent à des besoins de versionnage.
- La bonne pratique se choisit selon la cadence de déploiement, la taille d'équipe et le besoin de maintenir plusieurs versions.
- Adopter le trunk based exige d'abord une CI rapide, des tests fiables et des PR courtes, sinon la qualité chute.
FAQ : questions fréquentes
Section intitulée « FAQ : questions fréquentes »main), plusieurs fois par jour, via des branches ephemeres qui vivent moins d'une journee. Il evite le merge hell et alimente l'integration continue.