GitFlow : la méthodologie et la pratique

GitFlow est ce que l'on appelle un workflow, une stratégie d'utilisation de Git. Il en existe plein d'autre mais GitFlow est l'un des plus connu. Il a été pensé par nvie. Quel est son intérêt ?


This is a companion discussion topic for the original entry at https://blog.nathanaelcherrier.com/fr/gitflow-la-methodologie-et-la-pratique/

Merci Nathanael de nous aider à maitriser git.

Avant de découvrir gitflow, j’avais mis en place un workflow assez similaire mais qui ne faisait pas la distinction entre master et develop et évitait de faire les “doubles merge” à la fin d’une branche release/ ou d’une branche hotfix/ (l’un vers master, l’autre vers develop)
Ces “doubles merge” sont d’autant plus embêtants qu’ils peuvent donner lieu à une dissymétrie entre le merge avec master et celui en retour sur develop qui peut devoir gérer des conflits liés aux nouvelles branches feature/ qui ont été fusionnées entre le début et la fin de la release. Ainsi, il n’est pas garanti qu’une version sur master ait sa copie conforme sur develop. Ce qui empêche de repartir exactement d’une version de prod sans repartir de master (ce qui normalement n’est pas autorisé hors hotfix/).
Dans mon workflow, la branche master et develop sont les mêmes et la mise en prod se fait directement depuis master/develop après avoir validé le merge d’une branche release/ qui atteste que tout est OK (test unitaire, cleaning du code…). Cette mise en prod étant officialisée par le tag de version.
Ainsi TOUTES les branches partent de la même branche master/develop et ne merge que sur master/develop ce qui simplifie beaucoup la logique.

J’imagine qu’il doit y avoir une raison bien particulière pour avoir complexifié ce workflow pour obtenir gitflow. Savez-vous pourquoi ?

1 Like

Je ne pense pas que les “doubles merges” entre develop et master soient réellement problématique. Ces deux branches ne sont par principe jamais symétrique et c’est voulu.

La branche master doit toujours représenter l’environnement de production. Et il n’y a aucun cas où je souhaite partir de la version de production pour une nouvelle fonctionnalité. Ce serait me priver du travail de mes collègues. Le merge de master vers develop ne sert qu’a intégrer les corrections de bugs à la version en cours de développement (qui a de toute façon évoluée) pas à rendre les deux branches symétriques.

Utiliser une seule branche pour master et develop obligerait à deployer directement depuis la branche de release (pour ne pas déployer de nouvelles fonctionnalités non testées/debugées) et ensuite la réintégrer à la branche master/develop. Ce qui n’enlève en rien l’apparition de conflits si le développement du projet à progressé depuis et qui empêche d’utiliser la branche comme reflet de la production.

1 Like

Bonjour,

Merci pour votre article.
Nous avons besoin de quelques précisions car nous voulions adapter Git et surtout l’organisation que propose GITFLOW en remplacement de TFVC.
Voici notre contexte:

Nous utilisons Scrum avec des sprints de 2 semaines:

Nous avons 4 environnements : Recette, Preprod , Miroir client et Prod

chaque environnement est déployé sur un serveur IIS avec son propre URL
au début du sprint les devs corrigent les bugs, une fois les bugs corrigés, une version de recette est déployée sur environnement de recette pour être validée par les testeurs, si c’est validée, elle est ultérieurement déployée dans l’environnement de préproduction pour être validé par le client avant sa mise en production effective.

à chaque environnement un bogue peut être refusé et donc revenir au développeur.

Nos problèmes :

  • le client doit toujours attendre la finalisation d’un lot de fiche ( par sprint) pour bénéficier d’un correctif d’une fiche

  • le lot de fiche doit absolument être clôturé sinon on risque de livrer des bogues non validés

cas concret : nous avons un lot de 25 fiches à traiter pour le sprint 1 réparties entre 6 développeurs en fonction de la séniorité, la complexité et le domaine de compétence
Le 3ième jour du sprint 10 fiches sont traitées par les développeurs sur la branche de dev
L’équipe de teste demande une version pour pouvoir les tester.
Une fusion de la branche Dev et Release est alors effectuée.
les testeurs testent les 10 fiches livrées alors que les devs continuent sur de traiter les 15 fiches restantes
2 fiches ont été jugées non résolues par les testeurs : leurs corrections se fait sur la branche release et redescend par la suite sur dev ?
à la fin du sprint un des devs à pusher 80% de son travail sur une fiche mais n’a pas finalisé , sommes nous obligés de fusionner ce travail sur la release ou pouvons nous l’ignorer ?

d’une façon plus générale est-il recommandé de créer une branche par bogue ? par développeur ? par Sprint de dev?

Merci d’avance pour votre retour.