Pourquoi Gitflow ?
Dans une équipe, plusieurs développeurs travaillent en parallèle sur des fonctionnalités différentes tout en maintenant une version stable en production. Sans stratégie de branches, le chaos guette : conflits permanents, déploiements instables, hotfixes qui écrasent du travail en cours.
Gitflow, introduit par Vincent Driessen en 2010, propose un modèle clair et éprouvé pour structurer ce travail collaboratif.
Les 5 types de branches
Branche de production. Contient uniquement le code stable et livré. Chaque commit correspond à une release taguée (v1.0.0).
Branche d'intégration. Les features terminées sont mergées ici. C'est la branche de référence pour les développeurs.
Branche créée depuis develop pour chaque nouvelle fonctionnalité. Nommée feature/nom-de-la-feature. Mergée dans develop à la fin.
Préparation d'une version. Créée depuis develop, permet les derniers ajustements (bump de version, corrections mineures) avant merge dans main et develop.
Correctif urgent en production. Créé directement depuis main, mergé dans main ET develop une fois terminé.
Cycle de vie d'une feature
# 1. Créer la branche feature depuis develop git checkout develop git checkout -b feature/ma-feature # 2. Développer, committer... git add . git commit -m "feat: ajout de la fonctionnalité X" # 3. Merger dans develop (via Pull Request / Merge Request) git checkout develop git merge --no-ff feature/ma-feature git branch -d feature/ma-feature
Gitflow vs Trunk-Based Development
Adapté aux équipes avec des cycles de release planifiés, plusieurs versions en parallèle, ou des processus de validation stricts (ex: secteur bancaire, public).
Tout le monde commit sur main, releases fréquentes, feature flags. Adapté aux équipes matures avec une CI/CD très robuste (ex: startups, SaaS).
Outils
Git GitLab GitHub git-flow (CLI) SourceTree IntelliJ IDEA