Workflow Gitflow

Le workflow Gitflow n'ajoute pas de concept à celui du workflow de branches de fonctionnalités. En revanche, il attribue des rôles spécifiques à différentes branches et définit quand et comment elles doivent interagir.

Le workflow Gitflow utilise un référentiel central comme hub de communication pour toutes les équipes de développement. Comme dans le workflow de branches de fonctionnalités, les développeurs et développeuses travaillent en local et effectuent des Push de leurs branches vers le référentiel central. La seule différence est la structure des branches du projet.

Au lieu d'une branche main unique, ce workflow utilise deux branches pour enregistrer 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. Tous les commits de la branche main doivent comporter un tag indiquant un numéro de version.

Voici un exemple de scénario dans lequel le workflow Gitflow est utilisé.

Imaginez qu'un développeur nommé Andy doive travailler sur une nouvelle fonctionnalité feature-123 et qu'une développeuse nommée Lucy doive travailler sur une nouvelle fonctionnalité feature-456.

L'administrateur·trice crée une branche develop basée sur main et en effectue un Push vers le référentiel Git distant dans le Studio Talend.

Andy crée une branche andy-feature-123 basée sur la branche develop dans le Studio Talend et passe sur cette nouvelle branche.

Comme Andy, Lucy crée une branche lucy-feature-456 basée sur la branche develop dans le Studio Talend et passe sur cette nouvelle branche.

Andy et Lucy travaillent sur leur nouvelle fonctionnalité et créent des Jobs sur leur branche locale de fonctionnalité, puis effectuent un Push de leurs modifications vers le référentiel distant.

Pendant qu'Andy continue à travailler sur sa fonctionnalité, Lucy termine la sienne et se prépare à la publier.

Lucy effectue un checkout de la branche develop distante comme branche locale et passe sur cette branche develop.

Lucy fusionne ensuite ses Jobs de la branche de fonctionnalité lucy-feature-456 dans la branche locale develop à l'aide du menu Pull and Merge Branch.

Lucy effectue un Push de ses modifications sur la branche locale develop vers la branche distante develop.

L'administrateur·trice crée ensuite une branche release à partir de la branche develop mise à jour et effectue un Push vers le référentiel distant. Lucy termine sa sortie de version.

Elle peut supprimer la branche locale, qui n'est plus utile.

Lorsque la fonctionnalité est prête à être livrée, Lucy effectue un checkout de la branche main comme branche locale, fusionne les modifications de la branche release distante vers la branche main locale à l'aide du menu Pull and Merge Branch, puis effectue un Push de ses modifications vers la branche main distante.

Lucy passe ensuite sur la branche main distante et lui ajoute un tag contenant la version publiée.

La branche release doit être fusionnée dans la branche develop, qui peut contenir de nouvelles mises à jour depuis le début de la sortie de version.

Après la sortie de la version courante, les développeur·euses peuvent continuer à travailler sur les fonctionnalités de la version suivante, jusqu'au moment où il faudra éventuellement ajuster la version sortie.

Pour ajuster cette version, un·e développeur·euse effectue un checkout de la branche main comme branche de maintenance locale, corrige ce qui doit l'être et effectue un Push de ses modifications vers le référentiel distant. Une branche maintenance distante est créée.

Ce·tte développeur·se effectue un checkout de la branche main distante comme branche locale, effectue une action Pull and Merge Branch depuis la branche maintenance distante et effectue un Push depuis la branche main locale vers la branche main distante. Les ajustements apportés sur la branche maintenance sont à présent fusionnés dans la branche main distante.

Le·a développeur·euse ajoute un tag à la branche main distante, avec le numéro de correctif (hotfix) v1.0.1.

Comme les branches de livraison de version, les branches de maintenance doivent être fusionnées dans la branche develop. Les équipes de développement doivent effectuer cette fusion et supprimer toutes les branches locales qui ne sont plus utiles.