Git Flow

Git Flow est un modèle de branching Git proposé par Vincent Driessen en 2010, devenu populaire massivement dans les années 2010s. Définit un workflow strict avec multiple branch types ayant rôles précis : main (production-ready), develop (integration), feature/* (development new features), release/* (preparing releases), hotfix/* (urgent production fixes). Considéré comme overengineered pour la plupart des contextes modernes 2024 — Vincent Driessen lui-même reconnaît en 2020 que Git Flow n'est pas adapté Continuous Deployment.

Branches :
(1) main (ou master) — code production, chaque commit est un release tagué (v1.0, v1.1).
(2) develop — branche d'intégration, contient le code accumulating pour next release.
(3) feature/<feature-name> — créées depuis develop, mergées back vers develop quand done. Long-lived souvent (days to weeks).
(4) release/<version> — créée depuis develop quand préparation release, accepts only bug fixes (pas new features), mergée vers main ET develop quand release shipped.
(5) hotfix/<issue> — créée depuis main pour urgent prod fix, mergée vers main ET develop.

Workflow typique :
(1) feature dev : git checkout -b feature/login develop ; work ; merge to develop via PR.
(2) release prep : git checkout -b release/1.2 develop ; bump version, fix bugs ; merge to main + tag + merge back to develop.
(3) hotfix : git checkout -b hotfix/security-fix main ; fix ; merge to main + tag + merge back to develop.

Outils : (1) git-flow CLI extension (originally Vincent Driessen) — automate branch creation, merge, tagging ; (2) git-flow AVH edition (active maintained fork) ; (3) GitKraken, SourceTree have Git Flow UI ; (4) IDE plugins.

Problèmes pour modern Continuous Deployment :
(1) long-lived feature branches → merge conflicts énormes, drift develop vs feature ; (2) release branches = batch deployment opposite of CD ; (3) require manual coordination versions/tags ; (4) extra cognitive overhead (devs must understand 5+ branch types) ; (5) develop vs main split inutile si déploiement quotidien — both should be identical ; (6) hotfix flow assume long release cycles requiring out-of-band fixes — modern CD just commits to main with fix.

Quand Git Flow reste pertinent :
(1) software avec versioned releases distribuées clients (desktop apps, mobile apps avec versioning strict — iOS/Android apps still useful, library publishing semver) ; (2) regulated industries with formal release process (medical devices, automotive, aerospace) ; (3) on-prem enterprise software with quarterly releases ; (4) teams not yet mature CI/CD (transition phase from waterfall).

Alternatives modernes recommandées :
(1) Trunk-based Development — single branch + short feature branches + feature flags (Google, Facebook, Netflix scale) ;
(2) GitHub Flow — simplified : main + feature branches via PR + deploy from main. Default for SaaS continuous delivery.
(3) GitLab Flow — main + environment branches (production, pre-production, staging) — useful quand can't auto-deploy (regulatory) ou pour multi-tier deployment promotion.
(4) Release Flow (Microsoft) — trunk-based + release branches lightweight pour cherry-pick hotfixes.

Migration Git Flow → Trunk-based : (1) shorten feature branches (days max) ; (2) introduce feature flags ; (3) eliminate develop branch (merge to main directly) ; (4) automate deployments ; (5) cultural shift (commit small, integrate often). Compétences DOP-C02, AZ-400, GH-FOUND.