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’autres, mais Gitflow est l’un des plus connus. 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 développer sur une branche de type feature.

git checkout -b feature/<nom> develop

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

Je commence ainsi à 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 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. En effet, je ne veux pas que toutes les fonctionnalités de ma branche de développement se retrouvent 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 peine à 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 commencer 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 commencer 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 commencer 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. Tous 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.

ÉDIT :
Après lecture de cet article, certains 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.

Si vous avez des questions ou des remarques/conseils, n'hésitez pas à laisser un commentaire plus bas ! Je serais ravis de vous lire. Et si vous aimez l'article, n'oubliez pas de le partager avec vos amis.