Tutoriel Git : Gitflow ou trunk-based, choisir un modèle de branches

Git n’impose aucune organisation. Il vous donne les branches vues au chapitre précédent, à vous de décider lesquelles existent, qui les crée et quand elles fusionnent. Ce choix s’appelle un modèle de branches, et deux grandes familles se partagent le terrain : Gitflow et le trunk-based development. Ce chapitre présente les deux, avec leurs commandes réelles, et explique dans quel contexte chacun se justifie.

Ce que Gitflow est devenu

Gitflow a été décrit par Vincent Driessen en janvier 2010, dans un article intitulé A successful Git branching model. Le modèle a été massivement adopté, au point de devenir le réflexe par défaut de toute une génération de développeurs.

Le 5 mars 2020, son auteur a ajouté une mise au point en tête de son propre article. Elle mérite d’être lue avant d’adopter le modèle : pour une équipe qui pratique la livraison continue, il recommande explicitement un fonctionnement bien plus simple, du type GitHub Flow, plutôt que de faire entrer Gitflow au chausse-pied. Il précise que Gitflow garde tout son sens pour un logiciel explicitement versionné, ou dont plusieurs versions doivent être maintenues en production simultanément.

Autrement dit, la question n’est pas « Gitflow est-il bien ou mal », mais « qu’est-ce que je livre, et à quel rythme ».

Trunk-based development

Le principe tient en une phrase : une seule branche de long terme, main, sur laquelle tout le monde intègre son travail très souvent, au travers de branches de très courte durée de vie.

Une branche vit quelques heures, une journée, rarement plus. Elle est fusionnée dès que le travail est cohérent, même si la fonctionnalité n’est pas terminée : ce qui n’est pas prêt à être vu par les utilisateurs est masqué par un drapeau de fonctionnalité (feature flag) plutôt que retenu sur une branche. main est en permanence déployable, et c’est l’intégration continue qui garantit cette propriété.

# 1. partir de la dernière version de main
git switch main
git pull --rebase

# 2. une branche courte, pour une seule chose
git switch -c fix/calcul-prix

# 3. travailler, committer
git commit -am "Corrige le calcul du prix TTC"

# 4. publier et ouvrir une demande de fusion
git push -u origin fix/calcul-prix

# 5. après revue et validation de la CI, fusionner dans main
git switch main
git merge --no-ff -m "Fusionne fix/calcul-prix" fix/calcul-prix
git branch -d fix/calcul-prix

Merge made by the 'ort' strategy.
 app.js | 1 +
 1 file changed, 1 insertion(+)
Deleted branch fix/calcul-prix (was 711bcbc).

*   d7cdba6 Fusionne fix/calcul-prix
|  
| * 711bcbc Corrige le calcul du prix TTC
|/  
* 5b45117 Ajoute app.js
* 38b7dc5 Ajoute la doc

L’option --no-ff force un commit de fusion même quand un simple avancement aurait suffi. L’historique montre ainsi explicitement qu’une branche a existé et ce qu’elle contenait. Sans -m, Git ouvre l’éditeur configuré au chapitre 1 avec un message pré-rempli. En pratique, ce sont les boutons Merge pull request de GitHub et Merge request de GitLab qui font ce travail à votre place.

Les versions se marquent par des étiquettes sur main, sans branche dédiée :

git tag -a v1.0.0 -m "Première version publique"
git push origin v1.0.0

tag v1.0.0
Tagger: Damien Flandrin <dam@example.com>
Date:   Wed Sep 2 10:00:00 2026 +0000

Première version publique

Préférez toujours l’étiquette annotée (-a avec un message) à l’étiquette légère : elle enregistre l’auteur, la date et un commentaire. Et n’oubliez pas le message : sans -m, Git ouvre un éditeur, et en environnement automatisé la commande échoue.

error: there was a problem with the editor 'false'
Please supply the message using either -m or -F option.

Gitflow

Gitflow ajoute une seconde branche permanente et trois familles de branches temporaires.

Notez que la branche de production s’appelait master dans l’article de 2010. Les hébergeurs créant aujourd’hui des dépôts sur main, c’est ce nom qui est employé ici.

Gitflow à la main

Aucun outil n’est nécessaire, le modèle n’est qu’une discipline de branches.

# créer la branche d'intégration, une fois pour toutes
git switch -c develop
git push -u origin develop

# une fonctionnalité
git switch -c feature/livraison develop
git commit -am "Ajoute le calcul des frais de livraison"
git switch develop
git merge --no-ff -m "Fusionne feature/livraison" feature/livraison
git branch -d feature/livraison

# une version
git switch main
git merge --no-ff -m "Version 1.2.0" develop
git tag -a v1.2.0 -m "Version 1.2.0"

*   876ffba Version 1.2.0
|  
| * 269874d Fusionne feature/livraison
|/| 
| * afcc714 Ajoute la livraison
|/  
*   d7cdba6 Fusionne correctif/prix
|  
| * 711bcbc Corrige le calcul du prix
|/  
* 5b45117 Ajoute app.js

Gitflow avec l’outil git-flow

Un jeu de commandes existe pour automatiser ces enchaînements. Le projet d’origine n’est plus maintenu, c’est l’édition AVH qui l’est, disponible dans la plupart des gestionnaires de paquets sous le nom git-flow.

git flow init -d       # -d accepte tous les noms par défaut

Using default branch names.

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/root/a8/.git/hooks] 

Le cycle d’une fonctionnalité tient ensuite en deux commandes :

git flow feature start facturation
# … vous travaillez et committez …
git flow feature finish facturation

Switched to branch 'develop'
Updating 5b45117..61c7618
Fast-forward
 facture.php | 1 +
 1 file changed, 1 insertion(+)
Deleted branch feature/facturation (was 61c7618).

Summary of actions:
- The feature branch 'feature/facturation' was merged into 'develop'
- Feature branch 'feature/facturation' has been locally deleted
- You are now on branch 'develop'

Et celui d’une version en deux également. git flow release finish fusionne dans main, pose l’étiquette, puis reporte le tout dans develop :

git flow release start 1.1.0
# … mise à jour du numéro de version, derniers correctifs …
git flow release finish -m "Version 1.1.0" 1.1.0

*   1b1a31d Merge tag '1.1.0' into develop
|  
| *   48f5649 Merge branch 'release/1.1.0'
| |  
| | * eb133dd Prepare la version 1.1.0
| |/  
|/|   
* | 61c7618 Ajoute la facturation
|/  
* 5b45117 Ajoute app.js

Ce graphe illustre bien le reproche fait au modèle : trois commits de fusion pour une version qui ne contenait qu’une fonctionnalité.

Lequel choisir

Choisissez le trunk-based development si vous livrez une application web ou un service que vous déployez souvent, si une seule version est en production à la fois, si votre équipe est petite, et si vous avez des tests automatisés dignes de ce nom. C’est le cas de la grande majorité des projets web aujourd’hui, et c’est le modèle à retenir par défaut.

Choisissez Gitflow si vous publiez des versions numérotées que vos utilisateurs installent, si vous devez maintenir plusieurs versions en parallèle, si une phase de recette formelle sépare la fin du développement de la mise en production, ou si vous travaillez sous contrainte réglementaire imposant une traçabilité par version. Bibliothèques, applications de bureau, logiciels embarqués, versions sur site chez des clients : le modèle y garde toute sa pertinence.

Si vous débutez seul, ni l’un ni l’autre. Travaillez sur main, faites une branche quand vous tentez quelque chose d’incertain, et posez une étiquette quand vous êtes content. Vous adopterez un modèle le jour où vous serez plusieurs, et ce jour-là le trunk-based est le plus simple à mettre en place.

Un dernier conseil : n’adoptez pas un modèle parce qu’il est réputé sérieux. Un Gitflow appliqué par une équipe de deux personnes qui déploient tous les jours produit des branches release vides et des fusions inutiles. Le bon modèle est celui qui correspond à votre façon de livrer.

La suite

Vous avez maintenant les bases de Git. Trois directions valent le détour ensuite.

L’intégration continue d’abord, qui est le complément indispensable du trunk-based development : faire lancer vos tests automatiquement à chaque poussée. GitHub Actions et GitLab CI sont intégrés à ces plateformes et se configurent avec un simple fichier YAML dans votre dépôt.

Les demandes de fusion ensuite, pull requests sur GitHub, merge requests sur GitLab. Ce sont elles qui organisent la revue de code en équipe, et elles sont la porte d’entrée réelle vers main dans les deux modèles présentés ici.

Enfin, les commandes de secours : git bisect pour retrouver par dichotomie le commit qui a introduit un bug, git cherry-pick pour récupérer un commit précis d’une autre branche, et git worktree pour ouvrir plusieurs branches dans plusieurs dossiers en même temps.

Le sommaire complet reste accessible depuis le tutoriel Apprendre Git, et les autres tutoriels du parcours dans le hub Développement web.