Une branche de publication ou la branche principale doit-elle être étiquetée lorsque le gitflow est utilisé?
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, elle peut être trouvée par git describe --tags de la branche develop aussi. Voir # 374
tandis que n autre poste :
J'ai accidentellement installé la version 0.4.2-pre via homebrew aujourd'hui et j'ai été confus par la façon dont le balisage 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 la balise soit créée 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 de sortie si HEAD est une validation balisée et une version de développement si l'une des validations suivantes. Quelqu'un pourrait-il expliquer la logique derrière ce changement pour moi? 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:
il semble que la balise soit placée sur le maître.
Tout d'abord, vous ne pouvez pas baliser les branches, vous ne pouvez baliser que 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.)
Il est inutile de marquer le deuxième commit vert à partir du bas (l'enfant vert du commit marqué 'Only bugfixes!') Comme 'v1.0' car 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 objectif: trouver facilement des validations. Vous marquez un commit comme 'v1.0' afin de pouvoir retrouver facilement ce que vous avez publié 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 en raison 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.