Série Git - Les workflows git (5/5)

Quelle méthode pour collaborer avec Git ?

Simon ROUSSEAU included in inclus dans Git and series Introduction à Git

2024-04-18 2024-05-05 599 mots 3 minutes

Séries - Introduction à Git

Contenu

Nous entamons le dernier article de cette série sur Git. Nous avons précédemment décrit la manière dont fonctionnait Git et comment l’utiliser, les plateformes collaboratives et nous allons maintenant terminer sur la présentation de deux méthodes de collaboration sur le développement.

Nous allons ainsi présenter deux workflows très connus, Github flow et Gitflow, avec leurs avantages et inconvénients qu’il me semble important de connaitre.

1 Github flow

Le premier que nous allons explorer est Github flow.

Ce workflow propose une branche principale (master ou bien main la plupart du temps) à partir de laquelle seront créées et fusionnées les branches (hotfix et feature par exemple).

Voici un exemple de graphe présentant une branche principale (main) suivi de la création de deux branches feature(feature/1_toto et feature/2_tata) et d’une branche hotfix(hotfix/3_tutu) :

%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'gitGraph': {}} }%% gitGraph commit tag:"v1.0.0" branch feature/1_toto checkout main commit branch feature/2_tata checkout feature/1_toto commit checkout feature/2_tata commit checkout main merge feature/1_toto tag:"v1.1.0" commit branch hotfix/3_tutu commit checkout main merge hotfix/3_tutu tag:"v1.1.1" checkout feature/2_tata commit commit checkout main merge feature/2_tata tag:"v1.2.0"

L’avantage de ce workflow est qu’il est simple à mettre en œuvre, il est facilement compréhensible et limite les conflits lors de fusion de branches.

L’inconvénient est qu’il ne permet pas de dissocier les hotfix et les feature lors de la création des tags sur la branche principale.

Ce workflow s’adresse principalement sur les projets dont le cycle de vie du produit est simple et pour les équipes peu nombreuses.

2 Git flow

Le deuxième workflow est Git flow.

À l’inverse du premier, celui-ci dispose de deux branches principales (develop et master généralement).

Les branches feature sont créées et fusionnées à partir de la branche develop.

Afin d’intégrer les différentes modifications apportées à la branche develop dans la branche master, il faut ensuite passer par une branche de release (exemple release/1.1.0 pour la release de la version 1.1.0).

Les branches hotfix sont, quant à elles, créées et fusionnées directement sur la branche master puis répercutées sur la branche develop.

%%{init: { 'logLevel': 'debug', 'theme': 'dark', 'gitGraph': {}} }%% gitGraph commit tag:"v1.0.0" branch develop order:1 checkout develop commit branch feature/1_toto order:100 checkout develop commit branch feature/2_tata order:101 commit checkout main branch hotfix/1.0.1 order:5 commit id:"v1.0.1" checkout feature/2_tata commit checkout main merge hotfix/1.0.1 tag:"v1.0.1" checkout develop merge hotfix/1.0.1 checkout feature/2_tata commit checkout feature/1_toto commit checkout develop merge feature/1_toto commit branch release/1.1.0 order:70 commit id:"v1.1.0" checkout main merge release/1.1.0 tag:"v1.1.0" checkout develop merge release/1.1.0 checkout feature/2_tata commit commit

L’avantage de ce workflow est qu’il correspond bien au cycle de développement d’un produit avec :

Les branches feature/* permettant aux développeurs d’isoler leurs modifications ;
La branche develop permettant de mettre en commun les développements de l’ensemble de l’équipe sans impacter la branche master ;
Les branches release/* pour effectuer une recette (et éventuellement quelques correctifs) avant le passage en production ;
La branche master qui permet une mise en production à partir de laquelle seront taguées les versions ;
Les branches hotfix/* permettant aux développeurs d’isoler leurs modifications dans le cadre d’un correctif en production.

L’inconvénient est qu’il est plus lourd à mettre en place et nécessite un apprentissage pour les développeurs.

Astuces

Des outils comme https://github.com/nvie/gitflow permettent néanmoins de faciliter le travail et d’automatiser une partie des actions.

Ce workflow s’adresse donc plutôt à des produits dont on veut permettre une distinction forte entre les branches de feature et celles de hotfix ; dont on veut permettre des recettes complètes et potentiellement un peu plus longues (via les branches release/*) et dont les équipes sont un peu plus importantes avec une bonne connaissance de Git.