GitLab Flow ou git-flow?

D’abord git-flow c’est quoi ?

C’est une des première proposition de « bonne pratique » diffusée avec succès sur internet pour travailler en équipe sur des branches git.

https://git-flow.readthedocs.io/fr/latest/presentation.html

Pfff, faut encore apprendre des commandes ?

Un plugin permet d’automatiser les tâches fastidieuses de manipulation des branches.

Pour l’installer : https://git-flow.readthedocs.io/fr/latest/presentation.html#pre-requisites

Mais moi je merge dans GitLab !

Ah ? Toi aussi ?

Tu as vu que GitLab comme GitHub, préconise une méthode plus simple et plus souple que git-flow ?

GitLab Flow n’est PAS git-flow !

GitLab propose une méthode inspirée de la méthode GitHub qui elle même simplifie et corrige les « défauts » de la méthode git-flow.

https://docs.gitlab.com/ee/topics/gitlab_flow.html

Pour les non anglophones, un résumé en français va suivre bientôt…

Le post qui a tout déclenché

git-flow c’est tellement 2010… En 2020, même son créateur conseil d’utiliser la méthode GitHub :

Personnellement GLF ou GF peu importe, les deux ne sont pas très différent au sens où l’on fait un usage important des branches de fix et features et c’est ça la raison principale pour laquelle je demandais à Eloïs l’usage de GF.

Après concernant le rebasing, l’article ci-dessus semble être contre, moi je suis au contraire très favorable à son usage. Eloïs aussi apparemment, donc ce serait une petite variation par rapport à GF ou GLF.

Au final, comme je ne serai plus forcément un gros contributeur sur le dépôt Duniter je dirais que c’est à @elois de choisir l’une ou l’autre méthode ou encore autre chose. Avoir une branche master un peu plus vivante peut en effet être souhaitable.

Mais svp, des branches pour les featurs et les fix dès que possible et MR avec du --no-ff et là l’historique devient exploitable :slight_smile:

2 Likes

Oui je suis clairement un pro-rebase :stuck_out_tongue:

Des branches pour tout (sauf changement cosmétique) ça me va, et merge en --no-ff aussi :slight_smile:

Par contre, pour être franc je n’aime pas le fait de préfixer une branche pas un “type”, je préfère la préfixée par le nom du contributeur auquel elle appartient (c’est ainsi que l’on fonctionne dans Dunitrust).
Le type des changement étant déjà indiqué dans le nommage des commit, il faut évidemment définir une convention de nommage des commit, sur Dunitrust j’en avait défini une : doc/en/dev/conventions-git.md · dev · nodes / rust / Dunitrust · GitLab


Après lecture de l’article, voici la variante de gitlab flow qui me conviendrais :

  • master : branche principale de développement
  • branches de releases : 1-8-STABLE, 1-9-STABLE, etc
  • Ajout d’une branche qui pointe sur le même commit que la dernière branche de release stable, nom a trouver, pourquoi pas production.
1 Like

Je sais pas ce que ça vaut, j’ai vu passer ça :

postroutine> L'extension GIT qui implémente Gitflow n'est plus développé depuis 2012:  https://github.com/nvie/gitflow                                                                                _
postroutine> Donc je me demande: Est-ce que la méthode Gitflow est toujours utilisée en 2020?                                                                                                         _
postroutine> Où est-ce qu'il existe une meilleure méthode?                                                                                                                                            _
Link Mauve> Tu peux être intéressé par https://www.endoflineblog.com/gitflow-considered-harmful                                                                                                       _
Link Mauve> Perso j’aime pas du tout, je préfère largement avoir le développement qui se passe sur master

Perso, je me demande si on veut vraiment rendre les contributions encore plus complexes en mettant en place des flow git qui demandent une grande formation… Qu’on peut se permettre en entreprise, mais dans le logiciel libre ?

De tout façon, pour moi, c’est le mainteneur ou les responsables des merges requests qui doivent gèrer le flow.

Actuellement, je supprime systématiquement la branche de la MR après le merge de la MR.
Ainsi les contributeurs restent en dehors de la gestion des branches.

J’ai mal dû me faire comprendre.

Je ne demande pas tellement du Git Flow, je demande qu’on essaye de suivre certaines pratiques du genre :

  • pas de commit direct sur la branche principale (master ou develop), mais création de branches + merge en --no-ff (permet d’isoler et recontextualiser les développements)
  • avoir une/des branches de livraison pour pouvoir produire des hotfix

Le reste c’est accessoire. Mais les commits directs ou encore les merges en fast-forward c’est vraiment horrible. Quand je regarde l’historique Duniter c’est juste ignoble, impossible de comprendre visuellement ce qui s’est passé ! On a juste une bouillie de commits qu’il faut prendre un par un pour essayer de comprendre.

1 Like

Ok ça me va

1 Like

Du coup concernant le dépôt Duniter j’ai décidé d’adopter une approche de type git-flow, je viens d’ajouter les conventions git au dépôt : https://git.duniter.org/nodes/typescript/duniter/-/blob/dev/doc/git-conventions.md

2 Likes

Beau boulot ! Un peu intimidant mais nécessaire pour le cœur du cœur du système.

Je réfléchis de mon côté, pour mes projets, à la responsabilité du mainteneur de créer et suivre les branches clefs, nécessaire à la compréhension de l’historique, mais restant KISS (j’aime les autoroutes bien droites des rebases…).

Côté contributeurs, le nom de la branche qu’ils utilisent importe peu pour moi, je la fais supprimer automatiquement après le merge/rebase de la MR. Par contre, comme les commits seront intégrés à l’historique, ils doivent suivre une nomenclature.

Le top dans le client git utilisé serait d’avoir une complétion automatique des mots clefs de cette nomenclature quand on rédige le message… On peut toujours rêver ! :grin:

1 Like

Aussi un point sur lequel nous devrions nous accorder : acceptes-tu d’adopter la méthode git flow ?

C’est très facile à installer (sudo apt-get install git-flow sur Debian) et utiliser et permet de bien cadrer les actions git :

git flow init

Which branch should be used for bringing forth production releases?
- 1.6
- 1.7
- dev
- master
Branch name for production releases: [master] 

Which branch should be used for integration of the "next release"?
- 1.6
- 1.7
- dev
- master
Branch name for "next release" development: [dev] dev

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/home/cgeek/dev/duniter/.git/hooks] 

Je suis devenu fan et plus productif avec cet outillage.

2 Likes

Je vais expérimenter ça puis je te dirai si ça me conviens ou pas :slight_smile:

1 Like

OK très bien.

Pour se donner une idée : c’est juste une méthode, et l’utilitaire git-flow n’est là que pour fournir des alias à une série de commandes git. On peut donc suivre git flow sans utiliser le logiciel git-flow, voir ne respecter qu’une sous-partie de la méthode.

C’est une méthode très largement utilisée dans l’industrie informatique. Si j’en fais la promotion c’est que ma mission actuelle m’a obligée à la suivre, alors que j’en avais seulement entendu parler.

Si Duniter avait pu en bénéficier, l’historique Git serait certainement bien plus clair. :slight_smile:

2 Likes

Je viens de lire toute la méthodo git-flow via le lien que tu as donné, globalement ça me parait plutôt bien, il y a tout de même un point sur lequel je n’ai pas envie de suivre la méthodo :

Merger une branche de feature quand elle est terminée OK.
Mais perso j’ai besoin de la rebaser régulièrement (chaque fois qu’une autre feature a été mergée), pour pouvoir récupérer au fur et a mesure les autres changements sans avoir des conflits de dingues à gérer quand la feature est enfin prête.

C’est d’autant plus important que nous somme sur un mode de développement lent, une feature peut prendre plusieurs semaines (voir mois) avant d’être mergée, si la branche dev a beaucoup avancée depuis c’est ingérable.

Cette remarque est également valable pour toute branche dont la finalité est d’être mergée sur la branche dev

En soit, cela ne devrait pas affecter les commandes git générées par l’utilitaire git-flow.

1 Like

Oui rebaser est une bonne pratique et git flow n’empêche pas de le faire, bien au contraire mieux vaut le faire pour avoir de belles “bosses” de développement de features. :slight_smile:

Je n’ai rien à redire, je suis même plutôt content de voir cette lib C++ s’en aller :slight_smile: vivement que tu vires naclb également.

Par contre pour scryptb, la librairie a été retirée : désormais c’est Node qui fournit la fonction.

Je n’ai pas pu aller au bout des TF mais a priori ça se passe bien.

Merger

Pour donner l’exemple sur cette MR, si ta branche avait été nommée feature/wotb-rs alors tu aurais pu merger de deux façons :

git flow feature finish wotb-rs

Ou bien avec Git (ou le bouton “Merge” de GitLab) :

git merge --no-ff feature/wotb-rs

Ce qui ferait une belle bosse, ou disons un bel arbre dans l’historique Git (entre autres bénéfices) :

image

Bon là je l’ai fait en local pour l’exemple, mais je te laisse merger :slight_smile:

1 Like

Euh, des fois merger les sujets ensemble c’est pas une si bonne idée, la discussion est à peine compréhensible car Eloïs dit qu’il a décidé d’utiliser une approche git-flow puis un post plus loin je lui dis « hey, sinon on peut utiliser git flow ? »

Lecteur, si tu passes par ici, ne sois pas trop surpris.

2 Likes