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 de 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 concept ni aucune commande en dehors de ce qui est exigé pour le workflow de branche par fonctionnalité. Il assigne 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 versions. Bien évidemment, vous bénéficiez également de tous les avantages du workflow de branche par fonctionnalité : pull requests, expériences isolées et collaboration plus efficace.

Introduction

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.

Fonctionnement

Workflow Gitflow – Branches historiques

Branches develop et master

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

La première étape consiste à compléter la branche principale (master) par défaut avec une branche de développement (develop). Une solution très simple consiste à créer une branche de développement (develop) vide en local et d'en faire un push vers le serveur :

 git branch develop git push -u origin develop

Cette branche contiendra l'historique complet du projet, tandis que la branche principale (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 de développement (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

Branches de fonctionnalité

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 branche à partir de master, les branches de fonctionnalité (feature) utilisent la branche de développement (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 principale (master).

Workflow Gitflow – Branches de fonctionnalité

À toutes fins utiles, notez que lorsque les branches de fonctionnalité (feature) sont associées à la branche de développement (develop), elles constituent le workflow de branche par 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 de développement (develop).

Création d'une branche de fonctionnalité

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.

Terminer une branche de fonctionnalité

Lorsque vous avez terminé de développer la fonctionnalité, l'étape suivante consiste à merger la branche de fonctionnalité (feature) dans la branche de développement (develop).

Sans les extensions git-flow :

git checkout develop git merge feature_branch

Avec les extensions git-flow :

git flow feature finish feature_branch

Branches de livraison

Workflow Gitflow – Branches de livraison

Une fois que la branche de développement (develop) a acquis assez de fonctionnalités en vue d'une livraison (ou qu'une date de livraison prédéfinie approche), faites un fork d'une branche de version (release) à partir de la branche de développement (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 corrections 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 de version (release) est mergée dans la branche principale (master) et taguée avec un numéro de version. Il convient en outre de faire à nouveau un merge dans la branche de développement (develop), qui a certainement progressé depuis le début de la version.

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 version 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 version (release) est une autre opération de branching directe. À l'instar des branches de fonctionnalité (feature), les branches de version (release) sont basées sur la branche de développement (develop). Vous pouvez créer une branche de version (release) 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 version prête à être livrée, elle est mergée dans les branches principale (master) et de développement (develop), puis la branche de version (release) est supprimée. Il est important de faire un nouveau merge dans la branche de développement (develop), car il se peut que la branche de version (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 de version (release), procédez comme suit :

Sans les extensions git-flow :

 git checkout master git merge release/0.1.0

Ou avec l'extension git-flow :

 git flow release finish '0.1.0'

Branches hotfix

Workflow Gitflow – Branches hotfix

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

Il est recommandé de consacrer une ligne de développement aux corrections 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 de version (release) ad hoc qui fonctionnent de pair avec la branche principale (master). Vous pouvez créer une branche de maintenance (hotfix) 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 de version (release), une branche de maintenance (hotfix) est mergée à la fois dans les branches principale (master) et de développement (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

Exemple

Voici un exemple complet illustrant le workflow de branche par fonctionnalité : imaginons une configuration de dépôt avec une branche principale (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

Pour compléter les branches de fonctionnalité (feature) et de version (release), voici un exemple de branche de maintenance (hotfix) :

 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

Résumé

Nous avons discuté du workflow Gitflow. Gitflow est l'un des nombreux workflows Git que votre équipe et vous-même pouvez utiliser.

Voici quelques enseignements clés sur Gitflow :

  • Le workflow est idéal dans le cadre d'un workflow de développement basé sur des versions.
  • Gitflow fournit un canal dédié pour la mise en production de hotfix.

Le workflow Gitflow global est le suivant :

  1. Une branche de développement (develop) est créée à partir de master.
  2. Une branche de version (release) est créée à partir de develop.
  3. Les branches de fonctionnalité (feature) sont créées à partir de develop.
  4. Lorsqu'une branche de fonctionnalité (feature) est terminée, elle est mergée dans la branche de développement (develop).
  5. Lorsque la branche de version (release) est terminée, elle est mergée dans les branches de développement (develop) et principale (master).
  6. Si un problème est identifié dans la branche principale (master), une branche de maintenance (hotfix) est créée à partir de master.
  7. Une fois la branche de maintenance (hotfix) terminée, elle est mergée dans les branches de développement (develop) et principale (master).

Découvrez à présent le workflow de duplication (fork) ou consultez notre page Comparaison de workflows.

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrez maintenant