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 cinq principaux workflows pour vous aider à décider.

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

Ce que vous allez apprendre

Comparer les 5 workflows Git : centralisé, feature branch, Gitflow, forking, trunk-based
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.

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

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.

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

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

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

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

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

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

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

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

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

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 ?

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.