Workflows Git : Gitflow, Feature Branch, Trunk-Based

Le workflow de branching définit comment votre équipe organise ses branches, intègre le code et livre en production. Il n'existe pas de workflow universel, le bon choix dépend de la taille de l'équipe, du rythme de livraison et du type de projet. Ce guide compare les six workflows les plus répandus pour vous aider à décider.

Prérequis : Les branches en bref et Merge et conflits.

Ce que vous allez apprendre

Comparer les 6 workflows Git : centralisé, feature branch, Gitflow, GitHub Flow, trunk-based, GitLab Flow
Identifier forces et faiblesses de chaque stratégie de branchement
Choisir le workflow adapté à votre équipe, release cadence et CI/CD
Éviter les antipatterns courants (branches trop longues, merges massifs)

1. Centralized Workflow

Le plus simple : tout le monde travaille sur main. Le schéma ci-dessous montre une seule ligne d'historique, alimentée par plusieurs développeurs à tour de rôle. C'est le fonctionnement hérité de Subversion, et sa limite apparaît dès qu'un travail dure plus d'une journée : le code inachevé se retrouve sur la branche que tout le monde utilise, sans possibilité de l'isoler.

main : ─── C1 ── C2 ── C3 ── C4 ── C5 ───
            ↑     ↑     ↑     ↑     ↑
          Dev A  Dev B  Dev A  Dev C  Dev B

Pas de branches (ou très rarement)
Chaque dev fait pull --rebase puis push
Adapté aux équipes de 1-3 personnes sur un projet simple

2. Feature Branch Workflow

Chaque fonctionnalité est développée sur sa propre branche, puis intégrée via une PR.

main     : ─── C1 ────── C2 ─── M1 ─── M2 ───
                          │      ↑       ↑
feature/a:                └── C3 ┘       │
feature/b:                     └── C4 ── C5 ┘

Fonctionnement

Le cycle tient en cinq gestes qui se répètent pour chaque fonctionnalité. Les deux étapes qui font la différence en pratique sont la première et la dernière : partir d'un main à jour évite de traîner des conflits dès le départ, et supprimer la branche après le merge empêche l'accumulation de branches mortes que plus personne n'ose toucher.

Créer une branche depuis main : git switch -c feature/user-auth
Travailler et commiter
Pousser et ouvrir une PR
Review, approbation, merge
Supprimer la branche

Forces et faiblesses

Force	Faiblesse
Isolation du travail	Branches longues = merge complexe
Revue de code naturelle	Pas de convention sur le nommage des branches
Simple à comprendre	Pas de gestion des releases

C'est le workflow le plus répandu. Il convient à la majorité des projets.

3. Gitflow (Vincent Driessen, 2010)

Un workflow structuré avec des branches à rôle fixe, décrit par Vincent Driessen dans un billet publié le 5 janvier 2010. Lisez le schéma de bas en haut : le travail naît sur feature, remonte dans develop, se stabilise sur une branche release, et n'atteint main qu'au moment de la mise en production. Les hotfix sont le seul chemin qui court-circuite ce parcours.

main     : ─── v1.0 ──────────────── v1.1 ── v2.0 ───
                │                      ↑       ↑
hotfix   :      │              ─ fix ──┘       │
                │                              │
release  :      │               ─── RC1 ── RC2 ┘
                │              ↑
develop  : ─── D1 ── D2 ── D3 ── D4 ── D5 ── D6 ───
                │           ↑           ↑
feature  :      └── F1 ── F2           │
                           └── F3 ── F4 ┘

Les branches

La colonne « Durée de vie » est la clé de lecture : deux branches sont permanentes et ne sont jamais supprimées, les trois autres sont créées puis détruites à chaque cycle. La confusion la plus courante chez qui découvre Gitflow concerne main et develop : le code qui tourne chez vos utilisateurs est sur main, alors que develop contient l'intégration en cours, qui n'a jamais été livrée.

Branche	Durée de vie	Rôle
`main`	Permanente	Code en production (tags de version)
`develop`	Permanente	Intégration des features
`feature/*`	Temporaire	Développement d'une fonctionnalité
`release/*`	Temporaire	Préparation d'une version (stabilisation)
`hotfix/*`	Temporaire	Correction urgente en production

Cycle de release

L'étape 4 est celle qu'on rate le plus souvent : la branche de release doit être fusionnée dans les deux branches permanentes. Si vous oubliez develop, les corrections faites pendant la stabilisation disparaissent et reviendront comme des régressions à la version suivante. Le même raisonnement vaut pour un hotfix, qui part de main et doit lui aussi redescendre dans develop.

Les features sont mergées dans develop
Quand develop est stable, on crée release/2.0
Corrections de bugs sur la branche release
La release est mergée dans main et develop
main est taguée (v2.0)

Forces et faiblesses

Le rapport bénéfice/coût de Gitflow dépend entièrement de votre rythme de livraison. Sa structure est un atout réel quand vous devez maintenir plusieurs versions en parallèle chez des clients différents. Elle devient un poids quand vous livrez tous les jours, parce que chaque déploiement demande de traverser trois branches au lieu d'une.

Force	Faiblesse
Gestion des releases structurée	Complexe (5 types de branches)
Hotfixes clairs	Merge fréquents entre branches
Adapté au versioning strict	Cycle de release lent

4. GitHub Flow

Une version simplifiée du Feature Branch Workflow, pensée pour le déploiement continu.

main     : ─── C1 ── C2 ── M1 ── M2 ── M3 ── (deploy)
                       │    ↑     ↑     ↑
feature  :             └── C3 ┘   │     │
fix      :                    └─ C4 ┘   │
feature  :                         └── C5 ┘

Règles

Ces cinq règles ne se négocient pas indépendamment : elles ne tiennent que prises ensemble. La première est un engagement lourd, car « toujours déployable » signifie qu'un merge cassé bloque toute l'équipe. C'est ce qui rend la CI obligatoire plutôt que souhaitable dans ce modèle : sans tests automatisés fiables sur chaque PR, la règle 1 devient un vœu pieux.

main est toujours déployable
Créez une branche pour chaque changement
Ouvrez une PR tôt (draft si besoin)
Après review + CI verte, mergez dans main
Déployez immédiatement après le merge

Forces et faiblesses

La colonne de droite décrit un seul et même compromis vu sous trois angles : GitHub Flow échange la gestion des versions contre la simplicité. Si votre produit est un site ou une API que vous contrôlez de bout en bout, vous ne perdez rien. Si vous distribuez un logiciel que des clients installent chez eux et gardent plusieurs mois, l'absence de branche de version devient bloquante.

Force	Faiblesse
Très simple (2 types de branches)	Pas de gestion de releases
Déploiement continu natif	Nécessite une CI/CD robuste
PRs pour tout	`main` doit toujours être stable

5. Trunk-Based Development

Le mouvement le plus radical : tout le monde pousse sur main (le « trunk »), avec des branches très courtes (< 1 jour).

main : ─── C1 ── C2 ── C3 ── C4 ── C5 ── C6 ── (deploy)
                  ↑            ↑     ↑
short-lived:     └─ F1 ┘      │     │
                         └── F2 ┘   │
                              └── F3 ┘

Principes

Le premier principe entraîne mécaniquement le deuxième. Si une branche ne vit que quelques heures, une fonctionnalité qui demande deux semaines doit être intégrée inachevée, donc rendue invisible en production par un feature flag, c'est-à-dire une condition qui active ou désactive le code sans nouveau déploiement. C'est le prix d'entrée du trunk-based, et la raison pour laquelle il ne s'improvise pas.

Les branches vivent moins d'un jour (idéalement quelques heures)
Les features incomplètes sont cachées derrière des feature flags
L'intégration continue est essentielle (tests automatisés obligatoires)
Le déploiement est fréquent (plusieurs fois par jour)

Forces et faiblesses

Les faiblesses listées ici ne sont pas techniques mais organisationnelles. Aucune ne se corrige avec un outil : elles demandent des tests dans lesquels l'équipe a confiance et une revue de code rapide. La dernière ligne mérite attention si vous encadrez des débutants, car pousser plusieurs fois par jour sur la branche de production suppose de savoir évaluer seul le risque d'un changement.

Force	Faiblesse
Intégration continue réelle	Discipline rigoureuse requise
Pas de branches longues	Feature flags à gérer
Feedback rapide	Nécessite une excellente CI/CD
Réduit les conflits de merge	Difficile pour les juniors

6. GitLab Flow

Un compromis entre GitHub Flow et Gitflow, avec des branches d'environnement.

main          : ─── C1 ── C2 ── M1 ── M2 ───
                                  │     │
pre-production:                   M1'   M2'
                                  │     │
production    :                   M1''  M2''

Principe

L'idée centrale est de faire correspondre une branche à un environnement déployé, et de n'avancer que dans un seul sens : de main vers la pré-production, puis vers la production. Un commit ne peut donc pas atteindre la production sans être passé par les environnements précédents, ce qui donne une garantie que les workflows par tags n'offrent pas. La contrepartie est le maintien de plusieurs branches longues, avec le risque de dérive entre elles.

main est la branche de développement
Des branches d'environnement (pre-production, production) reçoivent les merges de main
Le merge vers production déclenche le déploiement
Variante : branches de release (1-stable, 2-stable) pour le support multi-versions

Comparatif global

Deux lignes de ce tableau valent plus que les autres pour un choix rapide. La ligne CI/CD requis est éliminatoire : si vous n'avez pas de tests automatisés, les colonnes GitHub Flow et Trunk-Based ne sont pas des options, quel que soit votre attrait pour elles. La ligne branches longues annonce votre coût de merge futur, car c'est la durée de vie d'une branche, pas le nombre de développeurs, qui produit les conflits difficiles.

Critère	Centralized	Feature Branch	Gitflow	GitHub Flow	Trunk-Based	GitLab Flow
Complexité	Faible	Faible	Élevée	Faible	Moyenne	Moyenne
Revue de code	Non	Oui (PR)	Oui	Oui (PR)	Optionnelle	Oui (MR)
Rythme de release	Variable	Variable	Planifié	Continu	Continu	Variable
Branches longues	Non	Possible	Oui	Non	Non	Oui (env.)
CI/CD requis	Non	Recommandé	Recommandé	Oui	Obligatoire	Oui
Taille d'équipe	1-3	2-20	5-50	2-30	5-100+	5-50

Comment choisir ?

Cherchez la ligne qui décrit votre contexte, pas celle qui décrit votre ambition. Un workflow se change plus facilement qu'une culture d'équipe : adopter le trunk-based sans tests automatisés produit une branche main cassée en permanence, ce qui coûte plus cher que le workflow qu'on cherchait à quitter. La progression naturelle va du feature branch vers GitHub Flow, puis vers le trunk-based à mesure que la CI/CD gagne en fiabilité.

Votre situation	Workflow recommandé
Seul ou 2-3 développeurs	Centralized ou Feature Branch
Équipe avec CI/CD mature	GitHub Flow ou Trunk-Based
Releases planifiées (SaaS, mobile)	Gitflow
Déploiement continu (web)	GitHub Flow ou Trunk-Based
Multi-environnements (staging, prod)	GitLab Flow
Très grande équipe	Trunk-Based (avec feature flags)

À retenir

Feature Branch : une branche par feature + PR, le plus courant
Gitflow : branches structurées (main/develop/feature/release/hotfix) pour les releases planifiées
GitHub Flow : simple, tout passe par PR, déploiement continu
Trunk-Based : branches très courtes, feature flags, le plus performant selon DORA
GitLab Flow : branches d'environnement, compromis entre GitHub Flow et Gitflow
Il n'y a pas de workflow parfait, choisissez selon votre contexte

Prochaines étapes

Maintenir un projet Accepter les contributions et gérer les releases.

Pull requests et code review Le workflow PR en pratique.

Gestion des branches Conventions de nommage et nettoyage.