Heading

Gitflow Workflow est un workflow Git qui aide au développement continu de logiciels et à la mise en œuvre des pratiques DevOps. Il a d’abord été publié et rendu populaire par Vincent Driessen à nvie. Le Workflow Gitflow définit un modèle de branchement strict conçu autour de la version du projet. Cela fournit un cadre robuste pour la gestion de projets plus importants.

Gitflow est idéalement adapté aux projets qui ont un cycle de publication programmé et à la meilleure pratique DevOps de livraison continue. Ce flux de travail n’ajoute pas de nouveaux concepts ou de nouvelles commandes au-delà de ce qui est requis pour le flux de travail de branche de fonctionnalité. Au lieu de cela, il attribue des rôles très spécifiques aux différentes branches et définit comment et quand elles doivent interagir. En plus des branches feature, il utilise des branches individuelles pour préparer, maintenir et enregistrer les versions. Bien sûr, vous pouvez également tirer parti de tous les avantages du flux de travail des branches de fonctionnalités : demandes de pull, expériences isolées et collaboration plus efficace.

Début

Gitflow n’est en fait qu’une idée abstraite d’un flux de travail Git. Cela signifie qu’il dicte quel type de branches à mettre en place et comment les fusionner ensemble. Nous aborderons les objectifs des branches ci-dessous. La boîte à outils git-flow est un outil en ligne de commande qui a un processus d’installation. Le processus d’installation de git-flow est simple. Les paquets pour git-flow sont disponibles sur plusieurs systèmes d’exploitation. Sur les systèmes OSX, vous pouvez exécuter brew install git-flow. Sur windows, vous devrez télécharger et installer git-flow. Après avoir installé git-flow, vous pouvez l’utiliser dans votre projet en exécutant git flow init. Git-flow est une enveloppe autour de Git. La commande git flow init est une extension de la commande par défaut git init et ne change rien dans votre dépôt autre que la création de branches pour vous.

Comment ça marche

Branches Develop et Master

Au lieu d’une seule master branche, ce workflow utilise deux branches pour enregistrer l’historique du projet. La branche master stocke l’historique de la version officielle, et la branche develop sert de branche d’intégration pour les fonctionnalités. Il est également pratique de marquer tous les commits de la branche master avec un numéro de version.

La première étape consiste à compléter la master par défaut avec une develop branche. Une façon simple de le faire est qu’un développeur crée une branche vide develop localement et la pousse sur le serveur :

git branch develop
git push -u origin develop

Cette branche contiendra l’historique complet du projet, tandis que master contiendra une version abrégée. Les autres développeurs doivent maintenant cloner le dépôt central et créer une branche de suivi pour develop.

Lorsque vous utilisez la bibliothèque d’extension git-flow, l’exécution de git flow init sur un repo existant créera la branche 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: 
Branch name for "next release" development: 
How to name your supporting branch prefixes?
Feature branches? 
Release branches? 
Hotfix branches? 
Support branches? 
Version tag prefix? 
$ git branch
* develop
master

Branches de fonctionnalités

Chaque nouvelle fonctionnalité devrait résider dans sa propre branche, qui peut être poussée vers le dépôt central pour la sauvegarde/collaboration. Mais, au lieu de se ramifier à partir de master, les branches feature utilisent develop comme branche mère. Lorsqu’une fonctionnalité est terminée, elle est fusionnée à nouveau dans develop. Les fonctionnalités ne doivent jamais interagir directement avec master.

Notez que les branches feature combinées à la branche develop constituent, à toutes fins utiles, le Workflow des branches de fonctionnalités. Mais, le Gitflow Workflow ne s’arrête pas là.

Feature branches sont généralement créées au large de la dernière develop branche.

Création d’une branche de fonctionnalité

Sans les extensions git-flow:

git checkout develop
git checkout -b feature_branch

En utilisant l’extension git-flow:

git flow feature start feature_branch

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

Finition d’une branche de fonctionnalité

Lorsque vous avez terminé le travail de développement de la fonctionnalité, l’étape suivante consiste à fusionner la feature_branch en develop.

Sans les extensions git-flow:

git checkout develop
git merge feature_branch

En utilisant les extensions git-flow :

git flow feature finish feature_branch

Branches de publication

Une fois que develop a acquis suffisamment de fonctionnalités pour une publication (ou qu’une date de publication prédéterminée approche), vous créez une branche release à partir de develop. La création de cette branche lance le prochain cycle de publication, de sorte qu’aucune nouvelle fonctionnalité ne peut être ajoutée après ce point – seules les corrections de bogues, la génération de documentation et d’autres tâches axées sur la publication doivent aller dans cette branche. Une fois qu’elle est prête à être expédiée, la branche release est fusionnée dans master et étiquetée avec un numéro de version. En outre, elle doit être fusionnée à nouveau dans develop, qui peut avoir progressé depuis le lancement de la version.

L’utilisation d’une branche dédiée pour préparer les versions permet à une équipe de peaufiner la version actuelle pendant qu’une autre équipe continue de travailler sur les fonctionnalités de la prochaine version. Cela crée également des phases de développement bien définies (par exemple, il est facile de dire :  » Cette semaine, nous préparons la version 4.0  » et de le voir réellement dans la structure du référentiel).

Faire des release branches est une autre opération de branchement simple. Comme les branches feature, les branches release sont basées sur la branche develop. Une nouvelle release branche peut être créée à l’aide des méthodes suivantes .

Sans les extensions git-flow:

git checkout develop
git checkout -b release/0.1.0

Lorsque vous utilisez les extensions git-flow :

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

Une fois que la version est prête à être expédiée, elle sera fusionnée dans master et develop, puis la branche release sera supprimée. Il est important de fusionner à nouveau dans develop car des mises à jour critiques peuvent avoir été ajoutées à la branche release et elles doivent être accessibles aux nouvelles fonctionnalités. Si votre organisation met l’accent sur la revue de code, ce serait un endroit idéal pour une pull request.

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

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 de correction

Les branches de maintenance ou "hotfix” sont utilisées pour corriger rapidement les versions de production. Les branches Hotfix ressemblent beaucoup aux branches release et feature sauf qu’elles sont basées sur master au lieu de develop. C’est la seule branche qui doit bifurquer directement de master. Dès que le correctif est terminé, il doit être fusionné à la fois dans master et develop (ou la branche actuelle release), et master doit être étiquetée avec un numéro de version mis à jour.

Avoir une branche de développement dédiée aux corrections de bugs permet à votre équipe de régler les problèmes sans interrompre le reste du flux de travail ou attendre le prochain cycle de publication. Vous pouvez considérer les branches de maintenance comme des branches ad hoc release qui travaillent directement avec master. Une hotfix branche peut être créée en utilisant les méthodes suivantes :

Sans les extensions git-flow :

git checkout master
git checkout -b hotfix_branch

Lorsqu’on utilise les extensions git-flow :

$ git flow hotfix start hotfix_branch

Similaire à la finition d’une release branche, une hotfix branche est fusionnée à la fois dans master et 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

Un exemple complet démontrant un flux de branchements de fonctionnalités est le suivant. En supposant que nous avons une configuration repo avec une master branche.

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

En plus du flux feature et release, un exemple hotfix est le suivant :

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

Résumé

Nous avons abordé ici le flux de travail Gitflow. Gitflow est l’un des nombreux styles de flux de travail Git que vous et votre équipe pouvez utiliser.

Certains éléments clés à connaître sur Gitflow sont :

• Le flux de travail est excellent pour un flux de travail logiciel basé sur les versions.
• Gitflow offre un canal dédié pour les correctifs vers la production.

Le flux global de Gitflow est :

1. Une develop branche est créée à partir de master
2. Une release branche est créée à partir de develop
3. .Feature

   branches sont créées à partir de develop

4. Quand une feature est terminée, elle est fusionnée dans la develop branche
5. Quand la release branche est terminée, elle est fusionnée dans develop et master
6. Si un problème dans master est détecté, une hotfix est créée à partir de master
7. Une fois que la hotfix est terminée, elle est fusionnée à la fois à develop et à master

Suivant , découvrez le workflow de bifurcation ou visitez notre page de comparaison des workflows.