Workflow Gitflow

Le workflow Gitflow est un workflow Git qui facilite le développement logiciel continu et l'implémentation des pratiques DevOps. Il a été publié et popularisé pour la première fois par Vincent Driessen de chez nvie. Le workflow Gitflow définit un modèle de branches strict conçu autour de la version du projet. Il s'agit d'un framework robuste pour la gestion de projets plus importants.

Gitflow est parfaitement adapté aux projets avec un cycle de livraison planifié et pour les bonnes pratiques DevOps de livraison continue. Il n'ajoute aucun nouveau concept ni aucune nouvelle commande en dehors de ce qui est exigé pour le workflow de branche de 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 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.

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 de développement et principale

Au lieu d'une seule branche main, ce workflow utilise deux branches pour sauvegarder l'historique du projet. La branche main 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 main un numéro de version.

La première étape consiste à compléter la branche main par défaut avec une branche develop. Une solution très simple consiste à 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 main 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: [main]
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
 main

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 main, les branches de fonctionnalité (feature) utilisent develop comme une branche parente. Lorsqu'une fonctionnalité est terminée, elle est à nouveau mergée dans la branche de développement. Les fonctionnalités ne communiquent jamais directement avec la branche principale (main).

Workflow Gitflow – Branches de fonctionnalité

À 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.

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é 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

Branches de livraison

Workflow Gitflow – Branches de livraison

Une fois que develop aura 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 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 release est mergée dans la branche main, 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 main et develop, puis la branche release est supprimée. Il est important de faire un nouveau merge dans 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 main
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 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 main et non sur develop. C'est la seule branche dont vous pouvez directement faire un fork à partir de main. Une fois la correction terminée, vous devez la merger dans main et develop ou dans la branche release courante, puis attribuer à main 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 release ad hoc qui fonctionnent de pair avec main. Une branche hotfix peut être créée comme suit :

Sans les extensions git-flow :

git checkout main
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 main et develop.

git checkout main
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 de fonctionnalité : imaginons une configuration de dépôt avec une branche main.

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

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

git checkout main
git checkout -b hotfix_branch
# work is done commits are added to the hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout main
git merge hotfix_branch

Résumé

Nous avons discuté du workflow Gitflow. Gitflow est l'un des nombreux workflows de 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 logiciel basé sur la livraison.
  • Gitflow fournit un canal dédié pour les corrections logicielles vers la production.

Le flux global de Gitflow est le suivant :

  1. Une branche develop est créée à partir de main.
  2. Une branche release est créée à partir de la branche develop
  3. Des branches feature sont créées à partir de la branche develop
  4. Lorsqu'une fonctionnalité est terminée, elle est mergée dans la branche develop.
  5. Lorsque la branche release est terminée, elle est mergée dans la develop et dans main.
  6. Si un problème est détecté dans la branche main, une branche hotfix est créée à partir de main.
  7. Une fois la branche hotfix terminée, elle est mergée dans develop et dans main.

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

Prêt à découvrir Git ?

Essayez ce tutoriel interactif.

Démarrer maintenant