Avoir une bonne stratégie avec Git Flow

Git est l’outil le plus utilisé pour versionner nos projets, c’est bien, c’est utile mais quand on commence à être plusieurs sur un même projet, les problèmes peuvent arriver très rapidement. Adopter une bonne stratégie en utilisant Git est donc de mise si nous voulons éviter tout ça. Dans cet article nous parlerons de Git Flow, une technique utilisée qui se base sur la création de branche. Nous verrons tout d’abord les principes de base avant de passer sur un cas pratique.

Pourquoi Git Flow ?

Ne vous est-il jamais arrivé de travailler en équipe sur un projet, et au moment de faire un git push, un message d’alerte vous prévient que votre version locale n’est pas à jour ? Du coup, vous faites un git pull pour vous mettre à jour afin de push mais… Catastrophe ! Git vous prévient qu’il y a un conflit. La charge de résoudre tous ces conflits vous incombe donc. Quand il ne s’agit que de quelques lignes cela peut passer, mais lorsqu’il s’agit de fichiers entiers, cela peut vite devenir fastidieux.

Pas de panique ! Git Flow est là ! Ce workflow est facile à comprendre et évite beaucoup de conflits. Il permet aussi une meilleure visibilité et gestion des releases et donc une mise en production en bonne et due forme. Normalement, Git Flow couvre l’ensemble des besoins standards pour la plupart des projets de développement. Git Flow fonctionne encore mieux si vous travaillez en suivant une méthodologie Scrum avec des sprints, comme Scrum. En effet, Git Flow fonctionne avec un système de features, c’est-à-dire que chaque nouvelle fonctionnalité à ajouter dans votre projet sera tagguée et aura sa propre branche avant d’être mergée dans la branche develop, du coup chaque user story pourra correspondre à une feature et chaque sprint à une release qui aura son propre tag de version.

Certains préfèreront utiliser Github Flow, qui est un peu la version légère de Git flow. Github Flow semble plus simple à appréhender et adapté aux déploiements en production plus récurrents : on n’attend plus d’avoir fini une release pour déployer. Il fonctionne avec 2 branches :

• master qui est la branche principale à partir de laquelle on déploie.
• XXX qui sera une branche tirée du master et sur laquelle on commit et ouvre des pull requests avant de merger sur le master, qui gardera un historique des pull requests.

Revenons à Git Flow. Il existe pas mal d’outils avec une interface graphique, en voici 2 principaux :

• Source Tree fait partie de la suite Atlassian (BitBucket, Confluence, Jira, etc.) et est très utilisé par les professionnels. Il fonctionne très bien et intègre Git Flow nativement.
  • Atouts : très stable, très utilisé dans les entreprises, on peut facilement le jumeler avec les autres applications Atlassian et propose la plupart des fonctionnalités de git
  • Inconvénients : selon mon expérience, il est très gourmand en ressources, les requêtes (pull et push) ne sont pas faites en asynchrones et bloquent toute l’application pendant qu’elles s’exécutent
• GitKraken est un nouvel outil développé par Axosoft. Il intègre aussi GitFlow. C’est ce que j’utilise et j’en suis plutôt satisfait.
  • Atouts : L’interface est très séduisante, l’application est légère et rapide, il suffit de faire un simple drag and drop pour merger deux branches.
  • Inconvénients : Cette application est encore très jeune, il lui arrive donc parfois encore de crasher.

Sinon, vous pouvez installer git-flow afin de l’utiliser dans un terminal.

Principe de base

La base de Git Flow réside dans un système de branches bien spécifique :

Non, ceci n’est pas un plan du métro. Sur le schéma, nous pouvons voir les deux branches principales :

• master qui garde le même rôle qu’avant. C’est la branche principale qui correspond à la version stable du projet, celle qui est en production et qui porte les tags des versions.
• develop est la branche de développement. C’est ici qu’on va tirer les branches pour travailler sur les features/releases, elle correspond à l’environnement de développement, on y prépare les changements en vue de la prochaine release dans master

ATTENTION : Il ne faut jamais travailler sur ces deux branches ! Donc pas de commit/push ici !

En plus des branches principales, vous constatez d’autres branches qui sont tirées dans tous les sens :

• feature/xxx est tirée de la branche develop afin de travailler sur une fonctionnalité (une user story contenue dans un sprint par exemple). Une fois cette feature terminée, on la merge dans develop afin de la rendre disponible pour la prochaine release. On essaye, dans la mesure du possible, d’éviter de créer plusieurs features qui utilisent des fichiers communs en même temps afin d’éviter les conflits.
• release/xxx est tirée de la branche develop. Elle regroupe toutes les features ajoutées depuis la dernière release (ou depuis le début du sprint) et que l’on veut mettre en production. C’est à ce moment-là que l’on fait les dernières vérifications, corrections de bugs, ajouts de fonctionnalités au dernier moment. Une fois que l’on a fini, on merge la release dans develop ET dans master en n’oubliant pas de changer le tag de la version.
• hotfix/xxx est à utiliser en cas d’extrême urgence ! Elle est dédiée à la correction de bugs de production sur master. On la tire donc de cette dernière, une fois le bug corrigé il faudra donc merger le hotfix dans master ET dans develop (attention aux conflits)

Ces branches sont fermées une fois qu’on les a mergées et donc disparaissent de votre Git. De plus, ces branches restent généralement en local car, dans la plupart des cas, on est seul à travailler sur une feature donc il n’est pas nécessaire de faire de push une fois qu’on a fait un commit (sauf si on travaille sur plusieurs machines).

Un cas pratique

Initialiser un dépot Git

Installez Git Flow sur votre ordinateur et créez un dossier dans lequel vous ajouterez un fichier. Rendez-vous dans ce dossier avec votre terminal et tapez la commande git init pour initialiser un dépot git. Ajoutez votre fichier avec la commande git add . (avec git donc), commitez git commit -m "Mon premier commit". Automatiquement Git va créer la branche master. Pour le moment rien de nouveau, on est dans un dépot Git tout ce qui a de plus normal.

Initialiser Git Flow

Afin de pouvoir travailler avec Git Flow, il va falloir créer la branche develop tirée à partie de la branche master. Pour cela, il suffit d’exécuter la commande git flow init. Quelques questions vont vous être posées afin de déterminer le nom des branches – en principe, on laisse les noms par défaut (il suffit d’appuyer sur la touche entrée sans rien écrire). Exécutez la commande git branch et vous verrez que vous avez changé de branche pour aller sur develop.

Nouvelle feature

Créons une nouvelle feature en tapant dans notre terminal git flow feature start main (où main est le nom de notre feature). Après l’éxecution de la commande, vous verrez des indications sur ce que Git Flow a fait. Il vient de créer la branche feature/main et nous a basculé dessus.

Ajoutons un fichier index.html dans notre projet et ajoutons-y du HTML. Une fois cela fait on peut commiter : git add index.html et git commit -m "Ajout de la page principale". Si nous avons besoin de publier notre commit sur un serveur distant, nous pouvons utiliser la commande git flow feature publish main. Elle se chargera de créer la branche sur le serveur distant et de push notre commit. Afin de récupérer les données il suffit de faire un git pull sur la bonne branche comme nous en avions l’habitude avec Git.

Une fois qu’on a terminé notre feature, il suffit de taper la commande git flow feature finish main. Git Flow va donc :

• fusionner la branche feature/main avec develop
• supprimer la branche feature/main en local et sur notre serveur
• nous balancer sur la branche develop.

Nouvelle release

Même principe que pour une feature, tapons la commande git flow release start v0.1 (par convention, on utilise un nom de version). A ce niveau, on peut changer le nom de la version dans nos fichiers readme.md, package.json, etc. Une fois qu’on a terminé avec nos vérifications, on fait un commit (git add puis git commit -m "Derniers correctifs") puis on termine (même principe que pour la feature) git flow release finish v0.1. Cette fois-ci, Git Flow va nous proposer de mettre un message pour le commit de la fusion avec master, une étiquette afin de taguer notre release et enfin un message pour le commit de la fusion avec develop.

Une fois tout cela validé, git flow va se charger de :

• merger notre release avec master
• tagger notre release (avec l’étiquette que nous avons choisie)
• merger la release avec develop
• supprimer la branche release/v0.1
• nous balancer sur la branche develop

Pour publier nos modifications, il suffit de taper la commande git push --tags. N’oublions pas non plus de pusher la branche mastergit push origin master.