Workflow Gitflow : Organisez vos Projets de A à Z

Le workflow Gitflow est un modèle de gestion des branches efficace pour organiser le développement logiciel. Il est adapté aux projets d'envergure. Le workflow Gitflow repose sur la séparation des environnements de développement, de production et des fonctionnalités. Voici un guide pratique pour comprendre et appliquer Gitflow avec quelques bonnes pratiques.

Attention : Le workflow Gitflow, bien qu'efficace pour de nombreux projets, n'est pas toujours adapté à toutes les équipes ni à tous les types de projets. Assurez-vous qu'il répond bien aux besoins spécifiques du projet avant de l'adopter pleinement. Une liste d'autres workflows gagnants en popularité est fournie à la fin de l'article.

Il est recommandé d'avoir des bases dans l'utilisation de Git. Un mémo Git est disponible ici.

 
I. Structure des Branches

Le workflow Gitflow utilise différentes branches pour structurer le développement :

• Main (master) : branche principale contenant le code de production stable.
• Develop : branche de développement principale où les nouvelles fonctionnalités sont intégrées en continu (issue du master).
• Feature * : branche spécifique pour développer de nouvelles fonctionnalités à partir de la branche develop.
• Release * : branche dédiée aux préparations de versions avant le déploiement en production (issue de develop).
• Hotfix * : branche de correction utilisée pour résoudre des problèmes critiques directement en production (issue du master).
• Bugfix * : branche de correction utilisée pour résoudre des problèmes non critiques depuis le code en cours de développement (issue de develop).
• Support : branche utilisée pour maintenir des versions anciennes ou spécifiques sans impacter les branches principales (hors Gitflow).

* : Ces branches sont temporaires. Une fois le code mergé dans la branche de développement (develop) ou de production (master), elles doivent être supprimées pour ne pas polluer inutilement le dépôt Git.

 
II. Utilisation Pratique du flow GitFlow

 
II.A Master / Main : La branche de production

La branche Master, aussi appelée Main, représente la version stable et prête à être déployée en production. Cette branche contient uniquement le code validé, testé, et déployable, garantissant ainsi que tout ce qui s'y trouve peut être utilisé directement par les utilisateurs finaux.

 

 

II.B Develop : La branche de développement principale

La branche develop est créée à partir du master. Cette branche regroupe toutes les nouvelles fonctionnalités en cours et constitue le terrain d'intégration continue.

git checkout main
git checkout -b develop

Note : Cette branche de développement n'est pas encore prête à être déployée en production, mais son contenu est considéré comme étant testé par les développeurs.

 

II.C Feature : Développement de Fonctionnalités

Chaque nouvelle fonctionnalité se développe dans une branche feature, dérivée de develop. Imaginons que l'équipe travaille sur l'ajout d'un panier d'achat :

git checkout develop # Positionnement dans la branche develop
git checkout -b feature/add-basket # Création de la branche de fonctionnalité
git push --set-upstream origin feature/add-basket # Envoyer la branche dans le dépôt Git distant

# Ajout de la fonctionnalité et commit
git add .
git commit -m "Ajout du panier d'achat"
git push

 
Une fois la fonctionnalité développée, il est recommandé de faire un rebase par rapport à la branche develop pour résoudre les conflits potentiels avant de pousser les modifications :

git rebase develop
git push --force-with-lease

 

Enfin, il est nécessaire de merger le code dans la branche develop. Il est recommandé de faire relire le code par un tiers avant tout merge via une "Merge Request" (MR) ou une "Pull Request" (PR).

 

II.D Release : La branche de livraison

Quand une série de fonctionnalités est prête à être livrée, on crée une branche release à partir de develop :

git checkout develop
git checkout -b release/1.0.0
git push --set-upstream origin release/1.0.0 # Envoyer la branche dans le dépôt Git distant

On réalise les tests d'intégration et de non régression pour s'assurer que la solution fonctionne parfaitement.

Une fois les tests terminés et les dernières corrections de dernière minute appliquées dans cette branche, la branche release est fusionnée dans le master (PR / MR ou manuellement) et un tag de version doit être créé :

git checkout master
git merge release/1.0.0

# Création du tag
git tag -a v1.0.0 -m "Version 1.0.0"
git push origin v1.0.0

 

Attention : Ne pas oublier de fusionner dans la branche develop les derniers correctifs effectués sur la branche de release :

git checkout develop
git merge release/1.0.0

 
II.E Gestion des Corrections Urgentes avec Hotfix

Si un bug critique survient en production, on créé une branche hotfix depuis le master. Cette branche permet de corriger rapidement un bug sans passer par la branche de développement (qui n'est pas prête à être envoyée en production) et une branche de release (qui peut prendre du temps à être testée avant d'être envoyé en production) :

git checkout master
git checkout -b hotfix/1.0.1
git push --set-upstream origin hotfix/1.0.1 # Envoyer la branche dans le dépôt Git distant

# Correction du bug et commit
git add .
git commit -m "Correction critique de bug"
git push

Une fois testé, la branche hotfix est ensuite fusionnée dans la branche master avec un nouveau tag de version :

# Merge du correctif dans la branche master
git checkout master
git merge hotfix/1.0.1

# Création du tag
git tag -a v1.0.1 -m "Version 1.0.1"
git push origin main --tags

 

Attention : Ne pas oublier de fusionner dans la branche develop le correctif :

git checkout develop
git merge hotfix/1.0.1

 

 

 

 

III. Avantages et Inconvénients du Workflow Gitflow

Gitflow est populaire pour les projets de développement logiciel collaboratif, mais comme tout modèle, il présente des points forts et des limitations à prendre en compte.

Avantages :

• Organisation structurée : Gitflow apporte une organisation claire avec des branches dédiées à chaque type de tâche (développement, nouvelles fonctionnalités, corrections, etc.).
• Historique de commits propre : Grâce à l’usage de branches spécifiques et aux merges bien définis, Gitflow permet de garder un historique de commits ordonné et lisible, facilitant le suivi et la compréhension de l’évolution du projet.
• Séparation des environnements de développement et de production : Avec des branches main et develop bien distinctes, Gitflow isole le code stable de la production du code en cours de développement, limitant ainsi le risque de livrer du code non testé en production. Ce workflow permet également de ne pas pousser des fonctionnalités qui ne doivent pas encore être déployées.
• Processus de livraison contrôlé : La branche release permet une stabilisation finale avant la mise en production, incluant des tests et ajustements de dernière minute pour garantir une version stable.

 

Inconvénients :

• Complexité accrue : Gitflow introduit de nombreuses branches (main, develop, feature, release, hotfix), ce qui peut être complexe à gérer, surtout pour les petites équipes ou les projets simples où ce niveau de structure n'est pas nécessaire.
• Ralentissement du déploiement : Pour les équipes cherchant un flux de livraison rapide, Gitflow peut s’avérer lourd et moins flexible, car chaque livraison passe par un cycle de release qui peut ralentir la cadence de déploiement.
• Adaptation nécessaire pour les pratiques CI/CD modernes : Gitflow peut être moins compatible avec les pratiques de déploiement continu (CI/CD) où des releases rapides et fréquentes sont essentielles. Dans ces cas, des workflows comme GitHub Flow ou Trunk-Based Development peuvent être plus adaptés.
• Risques de synchronisation avec la branche develop : La branche develop nécessite un suivi rigoureux. Des branches feature ou hotfix peuvent nécessiter des rebases ou des merges fréquents pour rester à jour, augmentant le risque de conflits et de complexité dans le code.
• Non adapté aux projets open-source ou simples : Pour des projets open-source avec des contributions externes ou pour des applications simples, Gitflow peut être excessivement structuré. Un workflow plus léger comme Trunk-Based Development pourrait être plus adapté.

 

IV. Alternatives à Gitflow

Gitflow est un modèle robuste, mais d'autres workflows existent :

• GitHub Flow : Un modèle simplifié pour les projets en déploiement continu.
• Trunk-Based Development : Utilisé pour les mises à jour fréquentes dans des environnements agiles.
• GitLab Flow : Une alternative orientée CI/CD et intégrée à GitLab.

Pour en savoir plus, explorez les ressources :

• Gitflow sur Atlassian
• GitHub Flow
• Trunk-Based Development

 
V. Conclusion

Le workflow Gitflow est un allié puissant pour structurer le développement de projets logiciels en séparant efficacement les environnements de développement, de test et de production. Son modèle de branches permet de gérer facilement les nouvelles fonctionnalités, les préparations de version, et les corrections de bugs, tout en maintenant un historique de code clair et lisible. Cependant, le workflow gitflow n'est pas sans inconvénients. Suivant le projet, un autre workflow peut être plus adapté.

 

Note : Contenu très partiellement généré avec de l'IA mais relu et beaucoup complété par un humain :).