Git Flow : définition, modèle de branchement et utilisation dans les projets

Qu’est-ce que Git Flow ?

Git Flow est un modèle de branchement Git qui définit une structure stricte de branches et de règles de fusion pour gérer le développement, les versions et les corrections. Vincent Driessen a publié l’article « A successful Git branching model » en janvier 2010, et depuis lors, Git Flow est devenu la norme de facto dans le développement d’entreprise Java et .NET. L’idée principale est de diviser le code en cinq types de branches avec différents niveaux de stabilité.

Selon Atlassian Git Tutorials, 2024, Git Flow est basé sur deux branches permanentes : main (anciennement master) et develop. Toutes les autres branches sont temporaires : feature, release, hotfix. Chaque type de branche a un cycle de vie et des règles de fusion clairement définis. Dans le développement mobile, Git Flow est utilisé dans les projets avec des cycles de version réguliers (2–4 semaines) et la prise en charge de plusieurs versions.

Git Flow se distingue des modèles simples (GitHub Flow) par la nécessité d’une branche develop distincte pour l’intégration. Cela ajoute une étape au processus de fusion, mais offre un isolement supplémentaire des fonctionnalités inachevées du code prêt pour la version.

Vincent Driessen et l’histoire de Git Flow

En 2010, Vincent Driessen a publié l’article « A successful Git branching model », qui est devenu l’un des plus cités dans l’histoire de Git. Le modèle a été créé pour un projet avec des versions fixes et une prise en charge parallèle des versions. En 2020, Driessen a reconnu que Git Flow est obsolète pour les pratiques modernes de CI/CD, mais le modèle reste pertinent pour les projets avec de longs cycles de version et la nécessité de prendre en charge les anciennes versions.

# Initialiser Git Flow
git flow init

# Créer une branche feature
git flow feature start "add-auth"

# Terminer la branche feature (fusion dans develop)
git flow feature finish "add-auth"

# Créer une release
git flow release start "1.2.0"
git flow release finish "1.2.0"

Branche Main : code de version et marquage

Main (anciennement master) est la branche principale contenant uniquement le code de version prêt pour le déploiement. Chaque commit dans main doit correspondre à une version spécifique du produit, marquée au format de versionnement sémantique, par exemple v1.0.0, v1.1.0. Aucun développement direct n’est effectué dans main — les modifications n’arrivent ici que par les branches release ou hotfix.

Selon semver.org, 2024, les tags dans main utilisent le format MAJOR.MINOR.PATCH. MAJOR est incrémenté pour les modifications incompatibles de l’API, MINOR pour l’ajout de fonctionnalités avec compatibilité ascendante, PATCH pour les corrections de bugs. Dans Git Flow, chaque fin de version crée automatiquement un commit dans main avec un tag de version.

La branche Main est la seule déployée en production. Pour les projets mobiles, cela signifie qu’un push dans main déclenche le pipeline de construction App Bundle ou IPA et la publication sur Google Play / App Store. Dans les paramètres CI/CD de GitLab, main est protégée contre le force-push et la suppression.

Versionnement sémantique et tags

Chaque commit dans main est accompagné d’un tag au format SemVer : vMAJOR.MINOR.PATCH. MAJOR — pour les modifications incompatibles de l’API, MINOR — pour les nouvelles fonctionnalités avec compatibilité ascendante, PATCH — pour les corrections de bugs. Exemple : v2.1.0 signifie la deuxième version majeure avec de nouvelles fonctionnalités et sans corrections de bugs. Dans Git Flow, les tags sont créés automatiquement lors de la fin d’une release ou d’un hotfix via la commande git flow release finish.

Branche Develop : ligne d’intégration du développement

Develop est la deuxième branche permanente dans Git Flow, conçue pour intégrer toutes les fonctionnalités terminées. Les développeurs fusionnent les branches feature dans develop après avoir passé la revue de code et les vérifications CI/CD. Develop contient la dernière version stable du code, incluant toutes les fonctionnalités implémentées du sprint en cours.

Selon DataSift Git Flow Guide, 2024, develop peut être temporairement instable en raison des intégrations en cours. Pour prévenir les problèmes, les équipes pratiquent l’intégration continue (CI) : chaque fonctionnalité doit passer une suite de tests complète avant d’être fusionnée dans develop. Si la CI échoue, le développeur corrige le code avant la fusion suivante. Develop est toujours liée à la version actuelle de main : immédiatement après une version, develop est synchronisée avec main par une fusion.

Branches Feature : développement de nouvelles fonctionnalités

Les branches Feature sont des branches temporaires pour développer des fonctionnalités individuelles, des corrections de bugs ou des expériences. Chaque branche feature est créée à partir de develop et fusionnée dans develop après achèvement. Le nom de la branche feature contient généralement le numéro de tâche ou une brève description : feature/APP-123-add-oauth, feature/redesign-profile. Dans Git Flow, les branches feature peuvent exister indéfiniment.

Selon Pro Git Book, 2024, les branches feature sont un environnement de développement isolé : les modifications dans une branche n’affectent pas les autres jusqu’à la fusion. Dans les projets mobiles, les branches feature sont synchronisées avec develop via rebase ou merge pour éviter les conflits importants lors de la finalisation. Il est recommandé de rebaser la branche feature sur develop avant de créer un MR.

# Création manuelle d’une branche feature (sans git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# Créer un MR dans GitLab via CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

Branches Release : préparation d’une version

Les branches Release sont des branches temporaires créées à partir de develop pour préparer une version. Lorsque develop contient suffisamment de fonctionnalités pour une nouvelle version, l’équipe crée une branche release/X.Y.Z (par exemple, release/2.1.0). Dans cette branche, seules les modifications finales sont apportées : incrémentation de version, mise à jour de la localisation, tests finaux, correction de bugs critiques.

Selon Atlassian Git Tutorials, 2024, la branche release résout un problème clé : isoler les modifications finales du développement parallèle. Pendant que la version est préparée, de nouvelles fonctionnalités pour la version suivante continuent d’être fusionnées dans develop. Après achèvement, la branche release est fusionnée dans main (avec un tag) et dans develop (pour synchroniser l’incrémentation de version).

Branches Hotfix : corrections urgentes en production

Les branches Hotfix sont des branches temporaires pour corriger d’urgence les bugs critiques en production. Le seul type de branche dans Git Flow qui est créé à partir de main au lieu de develop. Format du nom : hotfix/X.Y.Z+1 (par exemple, hotfix/2.1.1). Après achèvement, la branche hotfix est fusionnée simultanément dans main (comme une nouvelle version correctif) et dans develop (pour que la correction ne soit pas perdue dans les futures versions).

Selon DataSift Git Flow Guide, 2024, les branches hotfix doivent être aussi courtes que possible — seulement la correction et le test. Un hotfix ne doit pas inclure de nouvelles fonctionnalités ni de refactoring. Dans le développement mobile, le hotfix est utilisé pour corriger les plantages critiques (taux de crash > 0,1 %), les vulnérabilités de sécurité ou les bugs bloquants dans l’App Store.

Avantages et inconvénients de Git Flow pour le développement mobile

Git Flow offre une structure claire particulièrement utile pour les grandes équipes et les projets avec des versions régulières. Avantages : isolement des fonctionnalités inachevées dans les branches feature, possibilité de préparer une version sans bloquer le développement, prise en charge de plusieurs versions via les hotfix. Inconvénients : complexité pour les débutants, nécessité de rebaser régulièrement les branches feature, conflits avec les branches à longue durée de vie.

Selon Martin Fowler, 2024, le principal inconvénient de Git Flow est les branches feature à longue durée de vie. Si une fonctionnalité est développée pendant 2+ semaines sans synchronisation avec develop, le conflit de fusion devient significatif. Pour les projets mobiles, il est recommandé de synchroniser la branche feature quotidiennement via un rebase sur develop.

Git Flow n’est pas recommandé pour les projets avec déploiement continu (chaque commit dans main → production). Pour ces projets, GitHub Flow ou Trunk-Based Development offrent un modèle plus simple et plus rapide. Mais pour les projets avec des cycles de version et la prise en charge des anciennes versions, Git Flow reste le choix optimal.

Quand Git Flow est nuisible pour l’équipe

Git Flow devient un problème dans trois cas : équipes de moins de 5 personnes (complexité inutile), déploiement continu (retard de livraison), manque de discipline de rebase (les branches feature à longue durée de vie créent des conflits de fusion). Si une équipe consacre plus de 20 % de son temps à fusionner des branches et à résoudre des conflits — Git Flow n’est pas adapté à cette équipe, même si elle est grande.

Alternatives à Git Flow : GitHub Flow et Trunk-Based Development

Les alternatives à Git Flow offrent un processus plus simple pour les équipes pratiquant le CI/CD. GitHub Flow utilise une seule branche permanente (main) et des branches feature. Chaque fonctionnalité est créée à partir de main, après revue et CI elle est fusionnée dans main et immédiatement déployée. GitHub Flow est plus simple mais ne prend pas en charge l’isolement des fonctionnalités inachevées ni la préparation parallèle des versions.

Selon GitHub Docs, 2024, Trunk-Based Development (TBD) va encore plus loin : tous les développeurs travaillent dans une seule branche (trunk), utilisant des branches feature de courte durée de 1–2 jours. Les feature toggles contrôlent la visibilité du code inachevé. TBD nécessite une grande discipline de CI/CD et l’automatisation des tests.

• GitHub Flow — une main + branches feature, idéal pour le CI/CD et les petites équipes
• GitLab Flow — étend Git Flow avec des branches d’environnement (staging, production)
• Trunk-Based Development — une branche + feature toggles, CI/CD maximal, fusions minimales
• One Flow — Git Flow simplifié sans branche develop, seulement main + feature + release