Workflow Gitflow
Gitflow est un workflow Git hérité qui constituait à l'origine une stratégie novatrice et disruptive pour gérer les branches Git. Il a perdu en popularité au profit des workflows basés sur le tronc, qui sont désormais considérés comme des bonnes pratiques pour les pratiques modernes de développement continu et DevOps. Gitflow peut également être difficile à utiliser avec l'intégration et le développement continus (CI/CD). Ce billet présente Gitflow à des fins historiques.
Qu'est-ce que Gitflow ?
Gitflow est un modèle de branching Git alternatif qui utilise des branches de fonctionnalité et plusieurs branches primaires. Il a été publié et popularisé pour la première fois par Vincent Driessen de chez nvie. Comparé au développement basé sur le tronc, Gitflow dispose de davantage de branches plus longues et de commits plus importants. Dans ce modèle, les développeurs créent une branche de fonctionnalité et attendent que la fonctionnalité soit terminée pour la merger à la branche « trunk » principale. Ces branches de fonctionnalités au long cours nécessitent une plus grande collaboration lors du merge, car elles risquent davantage de dévier de la branche « trunk ». Elles peuvent également introduire des mises à jour conflictuelles.
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.
Ressource connexe
Commande git log avancée
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
Fonctionnement
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 developCette 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
mainBranches de fonctionnalité
Étape 1. Créez le dépôt
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).
À 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_branchLorsque vous utilisez l'extension git-flow :
git flow feature start feature_branchContinuez 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_branchUtilisation des extensions git-flow :
git flow feature finish feature_branchBranches 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.0Lorsque 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.0Ou avec l'extension git-flow :
git flow release finish '0.1.0'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_branchLorsque vous utilisez des extensions git-flow :
$ git flow hotfix start hotfix_branchComme à 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_branchExemple
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_branchOutre 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_branchRé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 hotfix 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.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Le blog Bitbucket
Parcours de formation DevOps
