Git Flow, GitHub Flow ou trunk-based : quel workflow Git choisir

Qu'est-ce qu'un workflow Git et pourquoi le choix compte

Un workflow Git est un accord d'équipe sur les branches qui existent, d'où elles partent, où elles sont fusionnées et ce qui est considéré comme prêt pour une release. Git lui-même n'impose rien de tout cela : sans accord, chacun travaille à sa façon, et au bout d'un mois le dépôt contient des dizaines de branches, personne ne sait ce qui est déployé et les fusions se transforment en heures de conflits.

Les modèles les plus connus sont Git Flow, GitHub Flow (une variante du Feature Branch Workflow) et le trunk-based development. Il ne s'agit pas d'« ancien contre nouveau », mais d'outils adaptés à des contextes différents : la fréquence de vos releases, le nombre de versions du produit maintenues en parallèle et la maturité de vos tests automatisés.

Git Flow : le modèle avec les branches develop et release

Git Flow a été décrit par Vincent Driessen en 2010. Le modèle repose sur deux branches permanentes :

• main (master dans les anciens projets) — uniquement le code publié ; chaque commit correspond à une release et reçoit un tag ;
• develop — la branche d'intégration où sont fusionnées les fonctionnalités terminées pour la prochaine release.

Et sur trois types de branches temporaires :

Git Flow avec Git seul

Le cycle d'une fonctionnalité et d'une release ressemble à ceci :

# fonctionnalité
git switch develop
git switch -c feature/cart-discounts
# ... commits ...
git switch develop
git merge --no-ff feature/cart-discounts
git branch -d feature/cart-discounts

# release
git switch -c release/1.4.0 develop
# ... numéro de version et corrections ...
git switch main
git merge --no-ff release/1.4.0
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0
git branch -d release/1.4.0

L'option --no-ff est essentielle dans ce modèle : elle crée un commit de merge même quand une avance rapide (fast-forward) serait possible, si bien que l'historique montre quels commits appartenaient à une même fonctionnalité ou release.

L'extension git-flow

Pour éviter de taper ces séquences à la main, il existe l'outil git-flow (on installe aujourd'hui généralement un fork maintenu, souvent appelé git-flow-avh dans les gestionnaires de paquets). Il ajoute des sous-commandes :

git flow init -d
git flow feature start cart-discounts
git flow feature finish cart-discounts
git flow release start 1.4.0
git flow release finish 1.4.0
git flow hotfix start 1.4.1
git flow hotfix finish 1.4.1

git flow init demande les noms des branches et des préfixes (avec -d, il accepte les valeurs par défaut), et les commandes finish effectuent toutes les fusions nécessaires, posent le tag et suppriment la branche temporaire. De nombreux clients Git graphiques savent aussi appliquer Git Flow via des boutons.

Avantages et inconvénients de Git Flow

Avantages : une structure claire, un statut du code évident (main = ce qu'ont les clients ; develop = la prochaine version), une phase de stabilisation dédiée et une gestion pratique des hotfixes. Cela convient bien aux applications mobiles, aux logiciels distribués, aux bibliothèques et aux firmwares — là où une release passe par la validation d'un store ou s'installe chez le client.

Inconvénients : beaucoup de branches et de fusions, des branches feature de longue durée qui divergent de develop, et des doubles fusions release et hotfix faciles à oublier. Pour un service web déployé plusieurs fois par jour, les branches release deviennent de la bureaucratie. L'auteur du modèle a d'ailleurs ajouté en 2020 une note à son article : pour un logiciel livré en continu, mieux vaut regarder des approches plus simples comme GitHub Flow.

GitHub Flow : branches courtes et pull request

GitHub Flow est une version allégée du Feature Branch Workflow. Ses règles tiennent en quelques points :

1. main est toujours fonctionnelle et prête à être déployée.
2. Tout travail se fait dans une branche partant de main, avec un nom explicite.
3. La branche est poussée régulièrement et une pull request (merge request) est ouverte pour la discussion.
4. Après la revue et un CI au vert, la branche est fusionnée dans main.
5. Ce qui est fusionné dans main est déployé immédiatement.

git switch main
git pull
git switch -c feature/new-payment
# ... commits avec des messages clairs ...
git push -u origin feature/new-payment
# on ouvre une pull request, on passe la revue et le CI, on fusionne dans main

Avantages : une seule branche permanente, un minimum de règles, un chemin rapide de l'idée à la production et une revue de code naturelle. Inconvénients : aucun emplacement prévu pour maintenir plusieurs versions ou stabiliser avant une release, et sans bons tests automatisés, « main toujours prête » reste un vœu pieux.

Une approche similaire, avec des branches d'environnement supplémentaires (par exemple staging et production), est parfois appelée GitLab Flow. Elle est utile quand le déploiement en production n'est pas instantané mais planifié ou soumis à une validation manuelle.

Trunk-based development

En trunk-based development, tous les développeurs intègrent leurs changements dans une seule branche (le trunk, c'est-à-dire main) fréquemment — au moins une fois par jour. S'il y a des branches, elles vivent quelques heures, pas des semaines. Les fonctionnalités inachevées arrivent dans main, mais restent masquées derrière un feature flag :

if (featureFlags.isEnabled("new-checkout", user)) {
    renderNewCheckout();
} else {
    renderOldCheckout();
}

L'avantage principal : presque plus de gros conflits, car les changements sont petits et fusionnés tant que tout le monde a le contexte en tête. Le modèle pratique l'intégration continue au sens littéral et convient aux équipes matures avec un CI rapide et une forte couverture de tests. Les branches de release sont admises, mais créées depuis le trunk juste avant la publication ; les corrections vont d'abord dans le trunk, puis sont reportées par cherry-pick.

Inconvénients : il faut de la discipline et de l'infrastructure — tests rapides, flags, monitoring. Un débutant hésite à commiter dans main chaque jour, et un CI faible transforme le trunk en branche cassée en permanence. Les flags doivent aussi être supprimés à temps, sinon le code se couvre de conditions mortes.

Comparatif Git Flow, GitHub Flow et trunk-based

Comment choisir le workflow Git de votre équipe

Répondez à quelques questions :

• Devez-vous maintenir plusieurs versions publiées ? Si des clients sont en 2.x et en 3.x et que les deux ont besoin de correctifs — Git Flow ou trunk-based avec branches release.
• À quelle fréquence déployez-vous ? Une fois par trimestre — Git Flow ne vous gênera pas. Tous les jours — choisissez GitHub Flow ou trunk-based.
• À quel point faites-vous confiance à vos tests ? Si le CI est lent et la couverture faible, commencez par GitHub Flow avec revue obligatoire et raccourcissez progressivement les branches.
• Quelle est la taille et l'expérience de l'équipe ? Pour une petite équipe ou des débutants, GitHub Flow est le plus simple : une seule règle, « main toujours fonctionnelle », et une pull request pour tout.

Conseil pratique : ne prenez pas Git Flow « parce que c'est l'usage ». Commencez par le processus le plus simple qui répond à vos besoins et ne le complexifiez que face à un problème concret — par exemple, quand une phase de stabilisation ou la maintenance d'anciennes versions devient nécessaire.

Des règles valables quel que soit le workflow

• Protégez main sur le serveur : push direct interdit, revues obligatoires et CI au vert avant fusion.
• Mettez-vous d'accord sur le nommage des branches : feature/, fix/, hotfix/ plus le numéro de ticket.
• Gardez les branches courtes : plus une branche vit longtemps, plus sa fusion est douloureuse. Récupérez régulièrement main dans votre branche via merge ou rebase.
• Choisissez une stratégie de fusion des pull requests (merge commit, squash ou rebase) et appliquez-la de façon uniforme.
• Marquez les releases avec des tags annotés selon le versionnage sémantique.

Un hotfix dans chaque modèle : un bug, trois processus

La différence entre les approches se voit le mieux sur une correction urgente en production.

Dans Git Flow, on crée hotfix/1.4.1 depuis main ; après correction, la branche est fusionnée dans main avec le tag v1.4.1 et obligatoirement dans develop (ou dans la branche release en cours, s'il y en a une). Oublier la seconde fusion est l'erreur classique : à la release suivante, le bug « revient ».

git switch -c hotfix/1.4.1 main
git commit -am "Corriger le calcul de la remise"
git switch main && git merge --no-ff hotfix/1.4.1
git tag -a v1.4.1 -m "Hotfix 1.4.1"
git switch develop && git merge --no-ff hotfix/1.4.1

Dans GitHub Flow, un hotfix est une branche courte ordinaire depuis main, avec une pull request traitée en priorité. Une fois fusionnée, elle part en production par le même déploiement automatique ; il n'y a pas de processus séparé.

En trunk-based, la correction est d'abord commitée dans le trunk ; si une branche release tourne en production, le commit y est reporté avec git cherry-pick -x <hash>. L'option -x ajoute au message une référence au commit d'origine, pour que le lien reste visible dans l'historique. Et si le problème vient d'une nouvelle fonctionnalité, il suffit souvent de désactiver son feature flag sans toucher au code.

Répondre en entretien à « quel workflow Git avez-vous utilisé ? »

Le recruteur ne vérifie pas que vous connaissez les noms, mais que vous comprenez les compromis. Une bonne réponse : nommer le modèle, décrire l'organisation des branches et des revues, et expliquer pourquoi il convenait au projet. Par exemple : « Nous utilisions GitHub Flow : branches depuis main, pull request avec revue et CI obligatoires, déploiement automatique après fusion. Nous n'avons pas pris Git Flow, car nous publiions plusieurs fois par semaine et les branches release n'auraient fait que nous ralentir. » Bonus : expliquer ce que vous changeriez si le processus grandissait.

Conclusion

Git Flow est un modèle strict avec les branches develop, release et hotfix, adapté aux produits à versions planifiées et à la maintenance de plusieurs releases. GitHub Flow est plus simple et convient à la plupart des projets web, tandis que le trunk-based development offre la vitesse maximale mais exige un CI mature et des feature flags. Choisissez votre workflow Git selon la fréquence des releases et la qualité des tests, pas selon la mode. Les trois approches, avec leurs commandes et leurs erreurs typiques, sont pratiquées dans le cours Git.