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.

Bonjour :vulcan_salute: et bienvenue @Mtunisie ! :tada:

Pour répondre à votre question je souhaite rappeler quelques principe de Gitflow:

  • chaque développement doit être fais sur un branche différente du develop et du master et ils ne doivent être mergés qu’une fois entièrement terminés
  • s’il s’agit d’un bug urgent reproductible en production il faut créer une branche hotfix directement depuis master pour regler au plus vite le problème et éviter de livrer des fonctionnalité non terminées ou non prévues.
  • la branche develop doit être le plus stable possible et donc déployable à tout moment (en passant par la phase de test sur release bien-sûr)
  • toutes les corrections sur release sont mergé sur master et develop, ensuite release devrait être supprimé. (une branche release par version, plusieurs tests peuvent être menés en même temps)

Je pense que si l’on suit ces principes vos problèmes sont résolus. C’est à dire que puisque le develop ne contient que des fonctionnalité terminé et stables les testeurs peuvent demander une version de test à tout moment pour livrer plus vite au client. Cette version de test ne contiendra pas de travail terminé à uniquement 80% puisqu’il reste sur la branche du bogue qu’il n’est pas fini.

Bonjour, merci pour toutes ces explications limpides, super article.
Je comprends très bien l’utilité des différentes branches cependant j’avais quelques petites questions, si vous pouvez m’éclairer et m’aider.

Tout d’abord est ce que ce type de workflow avec ses différentes branches pourrait être transposé vers TFS de chez Microsoft (le client chez qui je suis utilise TFS depuis des années et il ne serait pas évident de migrer vers Git pour le moment)?
Deuxième question… nous sommes actuellement dans un système de déploiement avec une livraison d’une nouvelle version tous les 3 mois (de v1.0 vers v2.0). Entre 2 versions, 4 upgrades sont livrés (donc upgrade généré depuis la version n-1 soit v1.1, v1.2, v1.3 et v1.4). Ces upgrades en général ne concernent pas la livraison de nouvelle version de dll ou exe mais d’autres fichiers composant également le setup. Cependant, dans certains cas exceptionnels ils pourraient concerner des dll/exe, par exemple dans le cas de correction de bug urgent ou une fonctionnalité mineure qui ne pourrait pas attendre la version du trimestre suivant. Donc au final, nous nous retrouvons dans la situation suivante : la version 1.0 qui est en production, la version 2.0 qui est en cours de développement par une équipe pour le trimestre suivant et le développement du premier upgrade 1.1 qui comporte quelques correctifs (et les suivants par la suite 1.2,1.3 et 1.4). Ma question est, dans votre workflow illustré dans votre blog, pouvez-vous me dire à partir de quelle branche créerez-vous notre upgrade et quel type de branche (hotfix, support,…)? Et comment appliquerez vous votre workflow sur notre modèle ? D’avance je vous remercie pour votre aide car je suis un peu perdu. Fabrizio