Tutoriel GitFlow : branches pour fonctionnalités, versions et hotfixes

Configurer GitFlow

Avant de profiter du modèle de branches structuré de GitFlow, vous devez l’installer sur votre machine et l’initialiser dans votre dépôt. Heureusement, ces deux étapes sont simples.

Pour utiliser GitFlow, vous devez déjà avoir Git installé. Pour en savoir plus sur l’installation de Git, consultez le tutoriel d’installation de Git.

Installer GitFlow

GitFlow est une extension de Git, vous devez donc l’installer séparément. Par défaut, elle n’est pas fournie avec Git. Le processus d’installation dépend de votre système d’exploitation.

Pour des instructions détaillées, consultez la documentation officielle.

Remarque : si l’extension GitFlow ci-dessus facilite la gestion des branches de fonctionnalités, des releases et des hotfixes avec des commandes simples, elle n’est pas strictement nécessaire. Vous pouvez suivre le flux GitFlow en utilisant les commandes Git standards — à condition de respecter les conventions de nommage et les pratiques de fusion. L’outil automatise et impose simplement le processus, ce qui est utile pour les équipes et les projets d’envergure.

macOS

Si vous utilisez Homebrew, le gestionnaire de paquets le plus populaire sur macOS, exécutez :

brew install git-flow-avh

Linux (Debian/Ubuntu)

Sur un système basé sur Debian, comme Ubuntu :

sudo apt-get install git-flow

Windows

Sous Windows, vous pouvez installer GitFlow via Git for Windows et ajouter Git Bash à votre terminal.

Pour vérifier que GitFlow est installé, exécutez :

git flow version

Initialiser GitFlow dans un dépôt

Avant toute chose, votre dépôt Git doit être initialisé pour utiliser GitFlow. Plus d’informations dans Comment initialiser et configurer un dépôt Git.

Une fois GitFlow installé, initialisez-le dans n’importe quel dépôt Git existant avec :

git flow init

GitFlow vous demandera de configurer plusieurs paramètres. Voici ce qu’ils signifient et comment faire les bons choix :

1. Noms des branches : on vous demandera les noms par défaut des branches.
1. Nom de la branche de production (par défaut : master)
2. Nom de la branche de développement (par défaut : develop)
2. Préfixes des branches de support : GitFlow utilise des conventions de nommage pour ses différents types de branches.
1. Branches de fonctionnalités : feature/
2. Branches de correction de bugs : bugfix/
3. Branches de release : release/
4. Branches de hotfix : hotfix/
5. Branches de support : support/ (rarement utilisées en pratique)
6. Préfixe des tags de version : v (par ex. v.1.2.0)

Les valeurs par défaut conviennent à la plupart des équipes, mais vous pouvez les adapter aux standards de nommage de votre organisation.

Exemple de sortie à l’initialisation :

git flow init

Which branch should be used for bringing forth production releases?
   - master
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [] v

Après l’initialisation, vous pouvez pousser la branche develop sur votre dépôt distant. Pour en savoir plus sur push et pull, consultez le tutoriel Git Push et Pull.

Utiliser GitFlow pour le développement

Une fois GitFlow initialisé dans votre dépôt, vous pouvez utiliser son modèle de branches pour piloter votre workflow. GitFlow fournit des commandes de haut niveau pour les fonctionnalités, les releases et les hotfixes, ce qui facilite la structuration et évite le chaos dans Git.

Dans les sous-chapitres suivants, nous verrons GitFlow en pratique.

Créer des branches de fonctionnalité

Les branches de fonctionnalité servent à développer de nouvelles capacités sans impacter la base de code principale.

Créez une branche de fonctionnalité avec :

git flow feature start <feature-name>

Cette commande crée une nouvelle branche depuis develop nommée feature/<feature-name>. Vous pouvez commencer à développer votre fonctionnalité et valider vos changements comme d’habitude.

Terminer les branches de fonctionnalité

Lorsque votre fonctionnalité est terminée et testée, finalisez-la avec : 

git flow feature finish <feature-name>

Cette commande :

• Fusionne votre branche de fonctionnalité dans la branche develop.
• Supprime la branche locale feature/<feature-name>.

En cas de conflits de fusion, résolvez-les manuellement puis terminez la fusion en suivant le flux standard de résolution de conflits de Git.

Si vous travaillez dans de grandes équipes où des pull requests doivent être créées et relues d’abord, vous ne pourrez pas utiliser directement la commande de fin GitFlow ; vous pouvez plutôt procéder ainsi :

1. Validez votre travail, puis poussez la branche :

git push origin feature/<feature-name>

2. Créez une pull request de feature/<feature-name> vers develop sur GitHub, GitLab, etc.
3. Demandez des relectures, lancez les tests et obtenez les validations.
4. Une fois approuvée, fusionnez via l’interface de la plateforme et supprimez la branche.

Pour en savoir plus sur GitHub et son utilisation, je recommande les parcours GitHub Foundations et GitHub Concepts. Dans d’autres équipes, vous pouvez suivre le flux standard git flow feature finish, mais pensez à demander une relecture de votre branche avant de la fusionner dans develop et à exécuter des tests pour garantir le bon comportement.

Créer des branches de release

Les branches de release servent à préparer une nouvelle version de production sans bloquer le développement en cours sur la branche develop.

Pour démarrer une release, exécutez :

git flow release start <version-number>

Cela crée une nouvelle branche nommée release/<version-number>, issue de develop.

Dans cette branche, vous finalisez généralement les numéros de version, corrigez des bugs mineurs, mettez à jour la documentation et le changelog.

Terminer les branches de release

Quand votre release est prête pour la production, terminez-la avec :

git flow release finish <version-number>

Cette commande :

• Fusionne la branche de release dans master et develop.
• Tague la release sur master (par ex. v1.0.0).
• Supprime la branche locale release/<release-number>.

N’oubliez pas de pousser vos changements et vos tags :

git push origin master
git push origin develop
git push --tags

# ou en version courte
git push origin master develop --tags

Créer des branches de hotfix

Les hotfixes servent aux correctifs urgents en production lorsqu’un bug est détecté sur la branche master.

Pour démarrer un hotfix :

git flow hotfix start <version-number>

Cela crée une branche hotfix/<version-number> à partir de master. Vous pouvez maintenant appliquer les changements et valider la correction.

Une fois terminé, finalisez avec :

git flow hotfix finish <version-number>

Cette action :

• Fusionne le hotfix dans master et develop.
• Ajoute un tag de correction sur master.
• Supprime la branche locale `hotfix/<version-number>`.

Poussez vos changements et vos tags comme d’habitude :

git push origin master develop --tags

Les hotfixes sont particulièrement efficaces, car ils permettent de corriger rapidement la production sans interférer avec le développement en cours sur la branche develop.

Imaginez que des fonctionnalités déjà fusionnées dans develop ne doivent pas encore sortir, mais qu’un bug critique en production doit être corrigé. 

C’est là que les hotfixes sont précieux : ils partent de master puis ne sont fusionnés que dans develop.

Exemple de branchement avec GitFlow

Parcourons deux workflows courants — un cycle de développement de fonctionnalité et une release avec un hotfix — pour voir GitFlow en action et le comparer aux commandes Git classiques.

En voyant les deux côtés, vous comprendrez mieux comment l’extension GitFlow simplifie le processus en encapsulant plusieurs étapes Git dans des commandes simples et standardisées.

Pour un rappel rapide des commandes Git classiques, consultez la fiche mémo Git complète. Pour une vue d’ensemble rapide de Git, lisez le tutoriel GitHub et Git pour débutants.

Workflow de développement d’une fonctionnalité

Supposons que vous implémentiez une nouvelle fonctionnalité permettant aux utilisateurs de s’authentifier dans votre application. Vous l’appelez user-authentication.

Avec GitFlow :

git flow feature start user-authentication

# Travaillez sur la fonctionnalité
git add .
git commit -m "feat: Implement basic user authentication"

# Une fois terminé :
git flow feature finish user-authentication

git push origin develop

Maintenant avec Git classique :

# Créer et basculer manuellement sur une nouvelle branche
git checkout -b feature/user-authentication develop

# Travaillez sur la fonctionnalité
git add .
git commit -m "Implement basic user authentication"

# Une fois terminé
git checkout develop
git merge feature/user-authentication
git branch -d feature/user-authentication
git push origin develop

Comme vous le voyez, GitFlow réduit le nombre de commandes et donc la complexité. C’est aussi moins source d’erreurs, comme fusionner par inadvertance dans la mauvaise branche.

Pour en savoir plus sur le fonctionnement des fusions dans Git, lisez Git Merge Tutorial : guide complet avec exemples.

Supposons maintenant que vous préparez la release 1.0.0. Mais peu de temps après sa publication, un bug critique est détecté et doit être corrigé via un hotfix. 

Avec GitFlow :

# Démarrer une release
git flow release start 1.0.0

# Derniers ajustements, mise à jour des numéros de version
git commit -am "Prepare release v1.0.0"

# Finaliser la release
git flow release finish 1.0.0
git push origin master develop --tags

Vous avez maintenant trouvé le bug, vous devez créer un hotfix :

# Démarrer un hotfix
git flow hotfix start 1.0.1

# Appliquer la correction
git commit -am "Fix login issue in production"

# Finaliser le hotfix
git flow hotfix finish 1.0.1
git push origin master develop --tags

Et refaire tout cela avec les commandes Git classiques :

# Release manuelle
git checkout -b release/1.0.0 develop

# Modifications
git commit -am "Prepare release v1.0.0"

# Fusions manuelles
git checkout master
git merge release/1.0.0
git tag -a v1.0.0 -m "Release v1.0.0"
git checkout develop
git merge release/1.0.0

# Supprimer la branche de release
git branch -d release/1.0.0
git push origin master develop --tags

# Hotfix manuel
git checkout -b hotfix/1.0.1 master

# Appliquer la correction
git commit -am "Fix login issue in production"
git checkout master
git merge hotfix/1.0.1
git tag -a v1.0.1 -m "Hotfix v1.0.1"
git checkout develop
git merge hotfix/1.0.1

# Supprimer la branche de hotfix
git branch -d hotfix/1.0.1
git push origin master develop --tags

Bonnes pratiques pour utiliser GitFlow

GitFlow est puissant et vous aide à gérer le code de votre équipe. Pour en tirer le meilleur, suivez quelques bonnes pratiques.

Elles permettent de garder des branches propres, de réduire les conflits de fusion et d’améliorer la productivité, surtout en contexte collaboratif.

Des noms de branches cohérents

La cohérence est essentielle en collaboration. Respectez les conventions de nommage par défaut de GitFlow, sauf si votre équipe a une bonne raison de les adapter.

Modèles recommandés :

• Branches de fonctionnalité : feature/<feature-name>
• Branches de release : release/<version-number>
• Branches de hotfix : hotfix/<version-number>

Utilisez aussi le kebab-case pour les noms multi-mots (par ex. feature/user-authentication).

Des changements petits et fréquents

Les branches de longue durée entraînent souvent des fusions douloureuses et d’énormes pull requests difficiles à relire. 

Je sais de quoi je parle : je suis déjà passé plusieurs fois par l’enfer des conflits de fusion — autant l’éviter si possible !

À la place, gardez des branches de fonctionnalité de courte durée et focalisées sur une seule tâche. Validez et poussez régulièrement pour éviter de perdre du travail ou de trop diverger de develop.

Des changements plus petits et incrémentaux sont plus faciles à tester, relire et intégrer.

Se synchroniser régulièrement avec develop

Quand vous travaillez sur une branche de fonctionnalité, ne prenez pas de retard. Récupérez régulièrement les derniers changements de develop pour minimiser les conflits de fusion :

git checkout feature/<your-feature>
git fetch origin
git rebase origin/develop

Rester synchronisé facilite l’intégration et maintient la compatibilité avec les travaux des autres.

Relire et tester avant de fusionner

Même si GitFlow permet la fusion directe via des commandes comme git flow feature finish, il est préférable d’utiliser des pull requests (PR) ou merge requests (MR) pour toutes les fusions vers develop et master.

Avantages :

• Permet la revue de code et les workflows d’approbation
• Déclenche les vérifications CI/CD automatisées
• Fournit une traçabilité claire des changements

C’est particulièrement critique en production, où la qualité prime.

Dépannage de GitFlow

Même avec un flux structuré comme GitFlow, des problèmes peuvent survenir, surtout en équipe ou avec des branches de longue durée. 

Cette section couvre les défis les plus courants et comment les résoudre efficacement.

Conflits de fusion

Les conflits de fusion sont fréquents lorsqu’on travaille à plusieurs sur la même base de code — et ils sont agaçants. Ils surviennent généralement quand deux branches ont modifié les mêmes lignes de code.

Étapes pour résoudre un conflit de fusion :

1. Interrompez le processus git flow finish.
2. Fusionnez manuellement la branche dans sa cible :

git checkout develop
git merge feature/<your-feature>

3. Git vous invitera à résoudre les conflits. Ouvrez les fichiers en conflit et cherchez les marqueurs comme :

<<<<<<< HEAD
Code from develop
=======
Code from feature branch
>>>>>>> feature/my-feature

4. Modifiez et nettoyez le code manuellement.
5. Une fois résolus, marquez les fichiers comme résolus :

git add <resolved-file>

6. Terminez ensuite la fusion avec :

git commit -m "resolve merge conflict …"

Nettoyer les branches obsolètes

Il arrive que votre dépôt contienne des branches feature, release ou hotfix périmées. Pour éviter toute confusion, gardez votre dépôt aussi propre que possible.

Procédez ainsi :

1. Lister toutes les branches locales :

git branch

2. Supprimer une branche locale :

git branch -d <branch-name>

3. Si la branche n’a pas été fusionnée et que vous êtes sûr de pouvoir la supprimer :

git branch -D <branch-name>

4. Supprimer une branche distante :

git push origin --delete <branch-name>

Il est essentiel de vérifier régulièrement vos branches et de nettoyer celles qui sont obsolètes afin de garder un dépôt propre.

Conclusion

GitFlow est un cadre robuste pour la collaboration, la clarté et le contrôle de votre workflow de développement. Que vous travailliez sur un projet personnel impliquant d’autres personnes ou au sein d’une grande équipe, GitFlow vous aide à rester organisé en séparant clairement développement de fonctionnalités, releases et hotfixes.

Quand j’ai commencé à utiliser GitFlow, ça a été un vrai déclic. Fini le chaos des fusions. Fini les hésitations sur la branche à utiliser. Chaque travail avait sa place, et chaque release suivait un processus reproductible et fiable. Avec le temps, j’ai introduit GitFlow dans toutes les équipes avec lesquelles j’ai travaillé. Et, à chaque fois, cela a apporté plus de structure, une collaboration plus fluide et moins d’erreurs.

Dans ce tutoriel, vous avez appris :

• Ce qu’est GitFlow et pourquoi il est utile
• Comment installer et initialiser GitFlow
• Comment travailler avec les fonctionnalités, les releases et les hotfixes
• Les bonnes pratiques pour éviter les écueils courants
• Comment adapter GitFlow aux workflows modernes avec les pull requests

Si vous êtes prêt à passer au niveau supérieur avec Git, essayez GitFlow dans votre prochain projet. Et si vous maîtrisez déjà les bases, envisagez de l’intégrer à votre pipeline CI/CD, à votre processus de revue, ou même à GitHub Actions.