Workflow Gitflow

Un workflow Gitflow est une conception de workflow Git publiée et popularisée par Vincent Driessen (nvie). Le workflow Gitflow définit un modèle de création de branche strict conçu autour de la livraison du projet. Cela fournit un framework solide pour la gestion de projets plus importants.

Gitflow est parfaitement adapté aux projets avec un cycle de livraison planifié. Ce workflow n'ajoute aucun nouveau concept ni aucune nouvelle commande en dehors de ce qui est exigé pour le workflow de branche de fonctionnalité. Il attribue plutôt des rôles très spécifiques aux différentes branches et définit comment et quand elles doivent interagir. Outre les branches de fonctionnalité (feature), le workflow utilise des branches individuelles pour la préparation, la maintenance et l'enregistrement des livraisons. Bien évidemment, vous bénéficiez également de tous les avantages du workflow de branche de fonctionnalité : pull requests, expériences isolées et collaboration plus efficace.

Outre l'idée abstraite du workflow Gitflow, il existe un ensemble d'outils git-flow plus concrets qui intègre des extensions d'outils de ligne de commande Git, Gitflow, spécialisés.

En réalité, Gitflow n'est qu'une abstraction d'un workflow Git. Cela signifie qu'il dicte quel type de branches doit être configuré et comment les merger. Nous aborderons les usages des branches ci-dessous. git-flow est un outil de ligne de commande avec un processus d'installation. Le processus d'installation de git-flow est simple. Les packages git-flow sont disponibles sur plusieurs systèmes d'exploitation. Sur les systèmes OSX, vous pouvez exécuter brew install git-flow. Sous Windows, vous devrez télécharger et installer git-flow. Une fois git-flow installé, vous pouvez l'utiliser dans votre projet en exécutant git flow init. Git-flow est un wrapper Git. La commande git flow init est une extension de la commande git init par défaut. Elle ne change rien dans votre dépôt et ne fait que créer des branches pour vous.

Branches develop et master

Ce workflow utilise deux branches au lieu d'une seule branche master pour sauvegarder l'historique du projet. La branche master stocke l'historique officiel des versions, et la branche develop sert de branche d'intégration pour les fonctionnalités. Il peut également être utile d'attribuer à tous les commits de la branche master un numéro de version.

La première étape consiste à compléter la branche master par défaut avec une branche develop. Une solution très simple est de créer une branche develop vide en local et de la pusher vers le serveur :

git branch develop
git push -u origin develop

Cette branche contiendra l'historique complet du projet, tandis que la branche master en contiendra une version abrégée. À ce stade, les autres développeurs devraient cloner le dépôt centralisé et créer une branche develop de suivi.

Lorsque vous utilisez la bibliothèque d'extensions git-flow, l'exécution de git flow init sur un dépôt existant permet de créer la branche de développement (develop) :

$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
 
$ git branch
* develop
 master

Il convient de créer une branche pour chaque fonctionnalité. Ces branches seront ensuite pushées vers le dépôt centralisé en vue d'une sauvegarde/collaboration. Cependant, au lieu de créer une nouvelle branche à partir de master, les branches de fonctionnalité (feature) utilisent la branche develop comme une branche parente. Lorsqu'une fonctionnalité est terminée, elle est à nouveau mergée dans develop. Les fonctionnalités ne communiquent jamais directement avec la branche master.

À toutes fins utiles, notez que lorsque les branches de fonctionnalité (feature) sont associées à la branche develop, elles constituent le workflow de branche de fonctionnalité. Toutefois, le workflow Gitflow ne se limite pas à cela.

Les branches de fonctionnalité (feature) sont généralement créées à partir de la dernière branche develop.

Sans les extensions git-flow :

git checkout develop
git checkout -b feature_branch

Lorsque vous utilisez l'extension git-flow :

git flow feature start feature_branch

Continuez votre travail et utilisez Git comme vous le feriez normalement.

Lorsque vous avez terminé le travail de développement sur la fonctionnalité, l'étape suivante consiste à merger la branche feature dans la branche develop.

Sans les extensions git-flow :

git checkout develop
git merge feature_branch

Utilisation des extensions git-flow :

git flow feature finish feature_branch

Une fois que la branche develop aura acquis assez de fonctionnalités en vue d'une livraison (ou qu'une date de livraison prédéfinie approche), créer une branche de livraison (release) à partir de la branche develop. La création de cette branche marque le début du cycle de livraison suivant. Ainsi, aucune fonctionnalité supplémentaire ne pourra être ajoutée. Dorénavant, cette branche sera uniquement dédiée aux correctifs de bugs, à la génération de documentation et à d'autres tâches axées sur la livraison. Une fois qu'elle est prête, la branche release est mergée dans la branche master, et Git lui attribue un numéro de version. Il convient en outre de faire à nouveau un merge de la livraison dans la branche develop, qui a certainement progressé depuis le début de la livraison.

En utilisant une branche dédiée pour préparer les livraisons, une équipe peut affiner la version actuelle tandis qu'une autre équipe continue de travailler sur les fonctionnalités de la livraison suivante. Cela permet également de créer des phases bien définies pour le développement (p. ex., il est facile de dire « cette semaine, nous préparons la version 4.0 » et de la voir réellement dans la structure du dépôt).

La création de branches de livraison est une autre opération de branching directe. À l'instar des branches feature, les branches release sont basées sur la branche develop. Une nouvelle branche release peut être créée comme suit.

Sans les extensions git-flow :

git checkout develop
git checkout -b release/0.1.0

Lorsque vous utilisez des extensions git-flow :

$ git flow release start 0.1.0
Switched to a new branch 'release/0.1.0'

Une fois la livraison prête, elle est mergée dans les branches master et develop, puis la branche release est supprimée. Il est important de faire un nouveau merge dans la branche develop, car il se peut que la branche release ait été soumise à d'importantes mises à jour auxquelles les nouvelles fonctionnalités doivent accéder. Si votre organisation met l'accent sur la revue de code, cette étape est propice à la création d'une pull request.

Pour terminer une branche release, utilisez les méthodes suivantes :

Sans les extensions git-flow :

git checkout develop
git merge release/0.1.0
git checkout master
git merge release/0.1.0

Ou avec l'extension git-flow :

git flow release finish '0.1.0'

Les branches de maintenance ou « hotfix » sont utilisées pour appliquer rapidement des patchs aux livraisons de production. Les branches hotfix sont très similaires aux branches release et feature, si ce n'est qu'elles sont basées sur la branche master et non sur la branche develop. C'est la seule branche dont vous pouvez directement faire un fork à partir de master. Une fois que le correctif est terminé, vous devez en faire un merge dans master et develop (ou dans la branche release courante), puis attribuer à master un numéro de version actualisé.

Il est recommandé de consacrer une ligne de développement aux correctifs de bugs : votre équipe pourra ainsi résoudre les problèmes sans devoir interrompre le reste du workflow ou attendre le cycle de livraison suivant. Vous pouvez considérer les branches de maintenance comme des branches release ad hoc qui fonctionnent de pair avec la branche master. Une branche hotfix peut être créée comme suit :

Sans les extensions git-flow :

git checkout master
git checkout -b hotfix_branch

Lorsque vous utilisez des extensions git-flow :

$ git flow hotfix start hotfix_branch

Comme à la fin d'une branche release, une branche hotfix est mergée à la fois dans la branche master et dans la branche develop.

git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch

$ git flow hotfix finish hotfix_branch

Voici un exemple complet illustrant le flow de branche de fonctionnalité : Imaginons une configuration de dépôt avec une branche master.

git checkout master
git checkout -b develop
git checkout -b feature_branch
# work happens on feature branch
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

Outre les flows feature et release, un exemple hotfix ressemble à ceci :

git checkout master
git checkout -b hotfix_branch
# Le travail est terminé, les commits sont ajoutés à la branche hotfix
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch

Voici quelques enseignements clés sur Gitflow :

• Le workflow est idéal dans le cadre d'un workflow de logiciel basé sur la livraison.
• Gitflow fournit un canal dédié pour les hotfix vers la production.

Le flux global de Gitflow est le suivant :

• Une branche develop est créée à partir de master.
• Une branche release est créée à partir de la branche develop
• Des branches feature sont créées à partir de la branche develop
• Lorsqu'une fonctionnalité est terminée, elle est mergée dans la branche develop.
• Lorsque la branche release est terminée, elle est mergée dans la branche develop et dans la branche master
• Si un problème est détecté dans master, une branche hotfix est créée à partir de master.
• Une fois la branche hotfix terminée, elle est mergée dans la branche develop et dans la branche master