De l'utilistation de git-flow dans la vraie vie

Je l’ai déjà utilisé sur plusieurs projets et honnêtement, c’est plutôt simple à comprendre.

Je trouve que le modèle de branche proposé est plutôt cohérent et à partir de là, les commandes sont assez logiques et encapsulent complètement le fonctionnement interne de git.

Même pour quelqu’un qui n’est pas très familier de la gestion de version, je pense que c’est accessible. Le système maintient deux branches permanentes en parallèle (develop et master) qu’il met à jour automatiquement et de manière parfaitement transparente en fonction des branches temporaires (features, releases, hotfixes…) ce qui fait que l’utilisateur n’a pas à s’inquiéter qu’il y ait un retard sur l’une ou l’autre branche.

Après, le risque c’est que ce n’est pas restrictif dans le sens ou personne ne pourra empêcher quelqu’un qui ne fait pas attention de développer sur la branche master par exemple. Je pense qu’il y a quand même besoin de comprendre un peu comment fonctionnent les différentes branches mais on peut laisser le système gérer toutes les fusions et c’est quand même un plus appréciable je trouve.

La différence principale avec un système de Pull Requests c’est que tout se passe sur un seul repository, donc difficile d’empêcher quelqu’un de tout casser (volontairement ou involontairement).

À noter que sur les IDEs de chez JetBrains, il y a même un plugin simple d’utilisation qui intègre les commandes directement dans l’interface du logiciel.

Perso, je l’utilise sur un de mes projets open-source, mais en « modifier ». Ok, j’ai une branche develop, une master (qui est nommé production, car la master contient le site compilé (GitHub Pages)) et je bosse avec un système de fork avec les sous branches (features, bugfix, etc.) sur le fork et pour lesquels je fais des PRs pour éviter justement le bazarre sur les branches develop et production.

J’ai également fait adopter ce système pour certains projets dans la boîte où je bosse, mais c’est pour des secteurs d’activité et des façons de travail qui ont un long processus. Typiquement, entre le temps où la fonctionnalité est sur le master, que c’est livré au client, et qu’ils l’utilisent en production par le client, ça peut prendre quelques mois, années.

Après, je pense que c’est majoritairement utilisé en web et Cie, car (de mon point de vue) ça facilite le processus de dev, en tout cas ça le rende plus clair.

PS: le plugin de JetBrains est une tuerie.

Avec git-flow + Semantic Versioning + Conventional Commits, on a (toujours de mon point de vue) le combot gagnant.