GitFlow : la méthodologie et la pratique

GitFlow est ce que l'on appelle un workflow, une stratégie d'utilisation de Git. Il en existe plein d'autre mais GitFlow est l'un des plus connu. Il a été pensé par nvie. Quel est son intérêt ?

Pourquoi avoir une stratégie d'utilisation de Git ?

Git est puissant mais il est généralement mal utilisé. Et un outil mal utilisé peut vite devenir contre-productif.

Dans le cas de Git, cela peut se traduire par des conflits à chaque commit/merge ou presque, des pertes de données (même s'il faut vraiment en vouloir), etc...

Comment fonctionne GitFlow ?

GitFlow est un ensemble de règles simples qui se basent sur le fonctionnement par branche de Git.

Voici le principe de base :
Notre projet sera basé sur deux branches : master et develop. Ces deux branches sont strictement interdites en écriture aux développeurs.

La branche master est le miroir de notre production. Il est donc logique que l'on ne puisse y pousser nos modifications directement.

La branche develop centralise toutes les nouvelles fonctionnalités qui seront livrées dans la prochaine version. Ici il va falloir se forcer à ne pas y faire de modifications directement.

Trois autres types de branches vont ensuite nous permettre de travailler :

  • feature
  • release
  • hotfix

Je développe des fonctionnalités

Je vais donc développer sur une branche de type feature.

git checkout -b feature/<nom> develop  

Si je développe une nouvelle fonctionnalitée, elle sera logiquement appliqué à la prochaine version : je crée donc ma branche à partir de la branche develop.

Je commence donc à travailler à partir du code mis à jour pour la nouvelle version.

git checkout dev  
git merge feature/<nom> --no-ff  
git branch -d feature/<nom>  

Lorsque j'ai fini mon travail, je rapatrie celui-ci sur la branche de développement et je supprime la branche feature qui est devenue obsolète.

Je prépare une nouvelle version pour la mise en production

Je vais donc travailler sur une branche de type release.

git checkout -b release/<version> develop  

Je crée la branche à partir de la branche develop, ainsi je pourrais lancer mes tests et appliquer mes corrections pendant que mes collègues commencent déjà le développement de nouvelles fonctionnalités pour la version suivante.

git checkout dev  
git merge release/<version> --no-ff

git checkout master  
git merge release/<version> --no-ff  
git tag <version>

git branch -d release/<version>  

Lorsque tous mes tests sont passés avec succès et que ma nouvelle version est prête à être mise en production, je pousse tout sur la branche master et je n'oublie pas d'appliquer mes corrections à la branche de développement.

Je crée aussi un tag sur le dernier commit de la branche de production avec mon numéro de version afin de m'y retrouver plus tard.

Et enfin je supprime la branche release car maintenant elle ne sert plus à grand chose.

Je corrige un bug en production

Je vais donc travailler sur une branche de type hotfix.

git checkout -b hotfix/<name> master  

Pour ce cas particulier je crée ma branche à partir du miroir de production car je ne veux pas que toutes les fonctionnalités de ma branche de développement se retrouve en production lors d'une simple correction de bug.

git checkout dev  
git merge hotfix/<name> --no-ff

git checkout master  
git merge hotfix/<name> --no-ff  
git tag <version>

git branch -d hotfix/<name>  

Mon bug étant corrigé, je dois l'appliquer sur le dev et la prod. Une fois encore je versionne avec un tag sur la branche master et je supprime la branche hotfix.

GitFlow, la surcouche

Vous trouvez ce que l'on a vu génial mais lourd à mettre en œuvre sur un projet ? Je comprends. Au départ on a du mal à se rappeler le nom des branches, les points de départ et de fin de chaque branche en fonction de la situation dans laquelle on est.

Heureusement, le concepteur de GitFlow a pensé à vous en codant une surcouche pour Git qui simplifie tout ça. Elle vous fournit de nouvelles commandes haut niveau comme :

git flow init : pour initialiser Git et GitFlow dans un projet.

git flow feature start <nom> : pour démarrer le développement d'une nouvelle fonctionnalité.

git flow feature finish <nom> : pour terminer le développement d'une nouvelle fonctionnalité.

git flow release start <version> : pour démarrer le développement d'une nouvelle release.

git flow release finish <nom> : pour terminer le développement d'une nouvelle release.

git flow hotfix start <version> : pour démarrer le développement d'un nouveau hotfix.

git flow hotfix finish <nom> : pour terminer le développement d'un nouveau hotfix.

GitFlow s'occupera pour vous de choisir les branches de départ, les branches de fin, de créer les tags et de supprimer les bonnes branches.

Bien-sûr, beaucoup d'autres commandes existent mais celles-ci sont à mes yeux les plus importantes.

Pour le reste, vous utiliserez les commandes Git habituelles.

Allez plus loin

Ce workflow est beau. Tout ceux qui l'ont mis en pratique ont sûrement progressé dans la qualité de leur travail. Mais à partir de ce workflow d'autres améliorations sont possibles.

Par exemple, l'automatisation des tests unitaires, fonctionnels et de performance ainsi que l'automatisation des déploiements en production et/ou en intégration directement à partir des précédents tests.

EDIT : Après lecture de cet article, certain de mes collègues m'ont demandé comment mettre en place GitFlow dans un projet plus complexe où les développeurs doivent maintenir plusieurs versions en simultanée. La question étant très pertinente j'ai écrit un autre article sur ce cas.


Tweetez moi si vous avez des questions ou des remarques.

Nathanaël Cherrier

Ingenieur de développement mobile et web pour Econocom. Passionné par le développement en général, mais plus particulièrement par le développement web et mobile, je vous raconte mes petits secrets.

Subscribe to Mindsers IT

Get the latest posts delivered right to your inbox.

or subscribe via RSS with Feedly!