Workflow Gitflow

Vue d'ensemble

Gitflow est un modèle de branchement structuré, popularisé par Vincent Driessen en 2010, conçu pour les projets avec des releases versionnées et planifiées. Au lieu d'une seule branche d'intégration, il utilise deux branches à longue durée de vie ainsi que trois types de branches de support, chacune ayant un rôle défini. Cette structure rend la gestion des releases explicite, au prix d'un peu plus de formalisme.

Les deux branches à longue durée de vie

Ces deux branches existent pendant toute la durée du projet — vous ne les supprimez jamais.

• main contient le code prêt pour la production. Chaque commit sur main correspond à une version publiée et est généralement tagué (par exemple v1.4.0). Si vous voulez savoir exactement ce qui tourne en production, vous consultez main.
• develop est la branche d'intégration où les fonctionnalités terminées s'accumulent entre les releases. Elle contient toujours les dernières modifications destinées à la prochaine release, mais ces modifications ne sont pas nécessairement stables.

Comme les deux branches sont permanentes, la relation entre elles ne se réinitialise jamais : develop est toujours « en avance » sur main de tout ce qui n'a pas encore été publié.

Les trois branches de support

Les branches de support sont éphémères. Chacune est créée pour un objectif précis, fusionnée une fois cet objectif atteint, puis supprimée. Les conventions de nommage (feature/, release/, hotfix/) rendent leur rôle évident dans la sortie de git branch.

Branches de fonctionnalité

Les branches de fonctionnalité partent de develop et sont fusionnées dans develop. Elles contiennent le travail sur les nouvelles fonctionnalités et n'interagissent jamais directement avec main — une fonctionnalité seule n'est jamais publiée ; elle fait partie de la prochaine release versionnée.

git switch develop
git switch -c feature/search   # create + check out feature/search
# ...work and commit...
git switch develop
git merge feature/search       # fold the feature into develop
git branch -d feature/search   # delete it once merged

git switch -c <name> crée la branche à partir de la branche courante et bascule dessus en une seule étape — c'est l'équivalent moderne de git checkout -b. Voir Git switch pour la commande complète. Garder les branches de fonctionnalité de courte durée limite leur dérive par rapport à develop, ce qui réduit les conflits de fusion.

Branches de release

Les branches de release partent de develop lorsque celui-ci est complet en fonctionnalités pour une release. Elles existent uniquement pour la finalisation — numéros de version, notes de release et dernières corrections de bugs — pendant que develop reste ouvert aux fonctionnalités du prochain cycle.

Lorsque la release est prête, la branche est fusionnée dans deux endroits :

• dans main, où elle est taguée avec le numéro de version ; et
• dans develop, afin que les corrections de stabilisation effectuées sur la branche de release ne soient pas perdues.

git switch -c release/1.4.0 develop
# ...bump version, fix last bugs, write release notes...
git switch main
git merge --no-ff release/1.4.0      # record an explicit merge commit
git tag -a v1.4.0 -m "Release 1.4.0"
git switch develop
git merge --no-ff release/1.4.0      # carry fixes back into develop
git branch -d release/1.4.0

--no-ff (no fast-forward) force Git à créer un commit de fusion même lorsqu'un fast-forward est possible, de sorte que la release soit préservée comme un point unique et visible dans l'historique plutôt que d'être effacée.

Branches de hotfix

Les branches de hotfix partent de main pour corriger un bug de production en urgence — sans attendre que le travail en cours sur develop soit prêt pour une release. Comme les branches de release, elles fusionnent dans les deux : main (taguée avec une version patch incrémentée) et develop, de sorte que le correctif soit également présent dans les releases futures.

git switch -c hotfix/1.4.1 main
# ...fix the bug and commit...
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       # don't reintroduce the bug later
git branch -d hotfix/1.4.1

Oublier la deuxième fusion — dans develop — est l'erreur classique de Gitflow : le bug réapparaît dans la prochaine release car le correctif n'a atterri que sur main.

Quand utiliser Gitflow

Gitflow brille lorsque vous publiez des releases distinctes et versionnées — applications de bureau, bibliothèques, applications mobiles soumises à la validation d'un app store, ou tout ce qui possède des numéros de version maintenus et des correctifs d'urgence occasionnels. Les branches de release et de hotfix explicites vous offrent un endroit clair pour stabiliser et corriger la production sans perturber le développement en cours. La nécessité de prendre en charge plusieurs versions publiées simultanément est le signal le plus fort indiquant que la structure de Gitflow sera payante.

Un cycle de release complet en un coup d'œil

En assemblant les pièces, une version parcourt les branches ainsi :

1. Les développeurs créent des branches feature/* depuis develop, travaillent, puis fusionnent chacune dans develop.
2. Lorsque develop est suffisamment complet pour une release, une branche release/x.y.0 est créée pour la stabilisation finale.
3. La branche de release fusionne dans main, est taguée vx.y.0, puis fusionne dans develop.
4. Si la production présente un problème, un hotfix/x.y.z part de main, est tagué, et fusionne dans main et develop.

main n'avance donc que par des fusions de release et de hotfix, et chaque commit dessus est une version publiable et taguée.

Les compromis

Cette structure est aussi le point faible de Gitflow. Les nombreux types de branches ajoutent de la surcharge, et la branche develop à longue durée de vie peut s'écarter significativement de main, rendant les fusions douloureuses. Les branches à longue durée de vie encouragent des intégrations importantes et peu fréquentes — le contraire de ce que recherche la livraison continue. Les équipes qui publient plusieurs fois par jour trouvent généralement Gitflow trop lourd et préfèrent l'approche plus simple des branches de fonctionnalité ou du développement trunk-based, où le travail s'intègre en continu dans une seule branche. Choisissez Gitflow lorsque la cadence des releases et la prise en charge de versions parallèles, et non la vitesse de déploiement brute, sont vos priorités.

Comparez-le avec les alternatives avant de vous engager : le workflow de fork pour les contributions open-source, et les simples branches de fonctionnalité pour la plupart des applications web qui se déploient depuis une seule ligne.

Pratique