Explications du workflow Git flow

Qu’est ce que Git Flow et comment l’implémenter ?

Travailler sur un projet git avec plusieurs contributeurs peut être compliqué et confus.

Ou du moins, si aucun workflow n’est utilisé pour l’utilisation de git.

C’est pourquoi un workflow a été conçu par certaines personnes (je ne sais qui) dans le but d’optimiser l’utilisation de git.

Ce workflow s’appelle git flow. Rentrons dans le vif du sujet !

Avertissement

Dans ce tutoriel, il se peut qu’il y ait des changements avec le git flow traditionnel.

Les idées de base sont présentes, n’hésitez pas à comparer cet article avec d’autres sur le web.

Nous avons essayé d’ajouter quelques améliorations, notamment sur le format des messages dans nos commits, en vue de pouvoir simplifier la création de changelog.

Le workflow `git flow`

Idées générales

Un des concepts les plus impportants est de garder une seule branche pour le déploiement de nouvelles versions en production, et une autre pour accumuler plusieurs nouvelles fonctionnalités avant la création d’une nouvelle version:

master : branche gardant l’historique de chaque tag de votre code (aussi appelée main)
develop : branche sur laquelle on va pousser de nouvelles fonctionnalités en vue d’une nouvelle version

Développement d’une nouvelle fonctionnalité

Prenons un exemple simple: vous développez une nouvelle fonctionnalité. Vous allez donc suivre ces étapes:

Vous partez de la branche develop, vous créez une nouvelle branche:

git checkout -b feature/my-awesome-feature
Faites votre magie avec le code. Faites autant de commits que vous voulez.
Une fois que votre code est prêt à être testé et relu par vos collègues, ouvrez une Merge / Pull request.
N’hésitez pas à rebase votre branche sur origin/develop afin d’être sûr d’avoir les derniers changements.

Pour une opération de rebase local:

git fetch -ap && git rebase origin/develop

Après cela, vous avez besoin de push force sur votre repertoire distant (à cause du rebase):

git push -f
Une fois que votre code est testé, a passé votre pipeline d’intégration continu, et est accepté par vos collègues, vous pouvez merge feature/my-awesome-feature dans develop.

Faites cela via l’UI de votre service Git (GitHub / Gitlab / etc.)

Note: Pour garder un historique propre sur develop, choisissez l’option squash and merge lors du merge: il n’y aura qu’un commit sur develop.

On va vous demander un message pour cet unique commit:

Dans l’idéal, vous pouvez utiliser ce format: type(scope): my commit message.

Avec:
- type une des valeurs suivantes: feat,fix,docs,breaking,build,ci,misc,refactor,style,test
- scope peut être n’importe quel mot.
D’autres formats existent et peuvent être utilisés.

L’idée derrière ce format, vous allez le voir plus tard, est de pouvoir les parser et créer des changelogs automatiquement.

Mais cela ne fait pas partie du workflow traditionnel. Vous pouvez donc faire ce que vous voulez.

Préparation d’une nouvelle version

Vous avez développé plusieurs fonctionnalités que vous estimez être prêts pour une mise en production, l’idée est de suivre ces étapes:

Créer une banche release/vx.x.x partant de develop
Si vous avez des tests d’intégration, appliquez les sur cette branche
S’il y a des bugs sur cette branche, vous pouvez les fix sur celle-ci
Une fois que c’est prêt, vous pouvez merge sur master.

Note: dans le workflow traditionnel, le merge sur master se fait en faisant un squash. Mais, comme dit plus haut, nous avons décidé de modifier un peu ce workflow. L’idée est de garder les commits venant de develop sur master. Un merge commit peut être présent et aussi simple que vX.X.X. Garder les commits formattés sur master va nous aider plus tard pour créer les changelogs d’une release à l’autre. On le verra plus tard dans l’article.
Créez une nouvelle version (avec un nouveau tag).
N’oubliez pas de rebase develop sur master afin de garder le même historique. develop doit être au courant de ce qu’il y a sur master. Toujours en avance.

Développement de hotfix

Parfois (pour ne pas dire tout le temps …), il y a des bugs sur la nouvelle version de votre code.

Certains bugs peuvent attendre la prochaine version pour être corrigés, mais d’autres non.

Ces bugs doivent être corrigés au plus vite. Git flow a un plan de bataille pour ce cas de figure:

Créez une branche partant de master: hotfix/my-hotfix par exemple
Corrigez le bug
Testez le hotfix:
- La correction est effective
- Pas de regression dans le code
Une fois que le fix est testé et approuvé, mergez sur master avec un squash.

Le message de commit doit être explicite, il peut ressembler à cela:

hotfix(scope): fix critical vx.x.x
Créez votre nouveau tag.
Rebase develop sur master pour garder un historique complet sur develop.

Notes importantes

A chaque changement sur master, ne pas oublier de rebase develop sur master:

git fetch -ap && git rebase origin/master et git push -f origin/develop
De même pour les branches qui partent de develop, quand celle-ci a changé:

git fetch -ap && git rebase origin/develop et git push -f origin/feature/my-awesome-feature

Appendix 1: `git flow` , un package permettant d’implémenter ce workflow facilement

En lisant de la documentation sur git flow, je peux comprendre que cela puisse paraître fastidieux et difficile à maintenir sur le long terme.

C’est pourquoi il existe un plugin à git qui permet de simplifier l’utilisation de ce workflow: git flow.

Personnellement je ne l’utilise pas car je suis habitué à ce workflow depuis quelques années maintenant.

Mais si vous le souhaitez, allez regardez la documentation de cet outil https://github.com/nvie/gitflow et commencez à l’utiliser !

Appendix 2: Créez des changelogs automatiquement entre chaque nouvelle version de votre code

Dans cet article, j’ai inclus quelques améliorations par dessus le git flow traditionnel.

Le principal étant d’avoir un format commun de message pour les commits.

Si vous choisissez de suivre ces indications, vous pourrez créer vos changelogs facilement.

Pour cela, vous devez installer un petit binaire appelé git-chlog.

Vous pouvez le trouver ici https://github.com/git-chglog/git-chglog

Je ne vais pas faire un tutoriel complet sur son utilisation, mais vous pouvez aller lire la documentation pour en comprendre l’utililité.

Je vais juste vous partager un exemple d’utilisation pour conclure sur cet article:

Vous avez une nouvelle version de votre code: v1.1.0.

Le tag précédent était v1.0.7. Vous voulez créer un changelog entre ces deux tags.

Vous pouvez simplement executer: git-chlog v1.1.0.. pour avoir la liste des commits parsés dans cette dernière version.

Si vous voulez un changelog complet: git-chlog simplement.

Aussi simple que cela !

Conclusions

Dans cet article j’ai voulu vous expliquer comment avoir un workflow git propre, permettant à vous et votre équipe d’optimiser votre temps et de se concentrer sur le plus important: le code.

J’espère que ce tutoriel vous aidera à comprendre ce qu’est git flow !

Je vous partage deux liens qui m’ont aidé à écrire cet article:

A plus tard,

Adem.