Une branche de publication ou la branche principale doit-elle être étiquetée lorsque le gitflow est utilisé?


16

Ce problème indique que:

D'après ce que j'ai compris, placer la balise sur la branche de publication avant la fusion (et non sur la branche principale) est en fait la bonne chose à faire. Voir # 374

tandis qu'un autre poste :

J'ai accidentellement installé la version 0.4.2-pre via homebrew aujourd'hui et j'étais confus par la façon dont le marquage fonctionne dans cette version. Auparavant (version 0.4.1), la balise était créée sur la branche principale, après que la branche de publication y avait été fusionnée. Il semble maintenant que le tag soit créé lors du dernier commit de la branche release, ce qui ne semble pas être une bonne idée pour moi. Surtout si vous avez un système de build qui s'appuie sur des balises git et crée une version finale si HEAD est une validation balisée et une version de développement si c'est l'une des validations suivantes. Quelqu'un pourrait-il m'expliquer la logique de ce changement? Et en ce qui concerne le versioning sémantique, je ne considérerais pas cela comme une bosse de version au niveau du patch!

Dans notre équipe, nous avons et avons eu plusieurs discussions à ce sujet. Certains indiquent qu'une balise doit être créée à partir de la branche principale tandis que d'autres préfèrent la branche de publication. Selon l'image gitflow:

entrez la description de l'image ici

il semble que la balise soit placée sur le maître.


1
Je sais que GitLab a du mal avec les balises sur les branches lorsque vous élaguez les branches plus anciennes, il serait donc préférable que la balise soit sur le maître. Je ne suis pas sûr des autres outils git.
HorusKol

'Le gitflow' implique que ce workflow (pauvre en OMI) est le workflow git standard ou officiel. Ça ne l'est pas.
Miles Rout

@MilesRout Quel est votre workflow git préféré?
030

pour mon cas, j'utilise les valeurs de la balise git pour nommer la version de l'application lors de la sortie, donc je la fais dans la branche de sortie.
Think Twice Code Once

Réponses:


16

Tout d'abord, vous ne pouvez pas baliser les branches, vous pouvez uniquement baliser les validations.

Vous devez baliser le commit que vous publiez réellement. C'est le point des validations de balisage de version. Si vous rencontrez un problème avec votre logiciel dans un environnement (de production ou autre), vous pouvez dire avec certitude que le problème a été introduit par le commit dont cette version est dérivée.

(C'est pourquoi les gens parlent de `` builds reproductibles '': afin qu'ils puissent être sûrs que leur processus de publication n'introduit pas de nouveaux bogues qui n'étaient pas présents dans leur environnement de prévisualisation / mise en scène, et que s'ils ont un bogue en production, le même binaire est en cours d'exécution sur leur machine lorsqu'ils vont le déboguer.)

Cela ne sert à rien de marquer le deuxième commit vert par le bas (l'enfant vert du commit marqué 'Only bugfixes!') Comme 'v1.0' parce que vous n'avez pas publié ce commit en production. Vous avez libéré le commit sur master. Vous pouvez même voir que git flow l'a marqué comme 'Tag 1.0'.

N'oubliez pas que les balises ont un but: trouver facilement des validations. Vous marquez un commit en tant que «v1.0» afin de pouvoir facilement trouver la chose que vous avez publiée en tant que version 1.0. Vous ne le balisez pas pour avoir une balise 'v1.0' quelque part dans votre arbre de commit vaguement près du commit que vous avez réellement publié.

Si vous rencontrez des problèmes pour trouver les balises de votre branche de développement, c'est un problème entièrement distinct. Corrigez l'outil que vous utilisez pour rechercher des balises. Ou mieux encore: n'utilisez pas git-flow. Il a l'air bien dans ce diagramme à cause des jolis points colorés et des lignes joliment disposées, mais en réalité, il ressemble à un réseau fou et désordonné de lignes et de points colorés.


3
You should tag the commit you actually release. Ainsi, si par exemple 20 validations qui doivent être publiées résident dans la branche de publication et que cette branche est fusionnée dans le maître, la validation de fusion qui a été créée doit être étiquetée afin de savoir ce qui a été publié?
030

1
Oui, la validation de fusion serait balisée. En tant que variante de git-flow, j'ai également vu créer / baliser une "version bump commit" directement surbranch:master
rmharrison
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.