Uma ramificação de liberação ou ramificação mestre deve ser marcada quando o gitflow é usado?

Este problema indica que:

Pelo que entendi, colocar a tag no ramo de lançamento antes de mesclar (e não no ramo mestre) é de fato a coisa certa a ser feita, e isso pode ser encontrado pelo git descrevem - tags do ramo de desenvolvimento também. Veja # 374

enquanto outro post :

Instalei acidentalmente a versão 0.4.2-pré via homebrew hoje e fiquei confuso com a maneira como a marcação funciona nessa versão. Anteriormente (versão 0.4.1), a tag era criada no ramo mestre, depois que o ramo de liberação foi mesclado a ele. Agora parece que a tag foi criada no último commit do ramo de lançamento, o que parece não ser uma boa ideia para mim. Especialmente se você tiver um sistema de construção que depende de tags git e criar uma versão de lançamento se HEAD for uma confirmação marcada e uma versão de desenvolvimento se uma das seguintes confirmações. Alguém poderia me explicar a lógica por trás dessa mudança? E com relação ao controle de versão semântico, eu não consideraria esse um problema de versão no nível do patch!

Em nossa equipe, tivemos e tivemos várias discussões sobre isso. Alguns indicam que uma tag precisa ser criada a partir do ramo mestre, enquanto outros preferem o ramo de liberação. De acordo com a imagem do gitflow:

parece que a etiqueta foi colocada no mestre.

Em primeiro lugar, você não pode marcar ramificações, você pode apenas marcar confirmações.

Você deve marcar o commit que realmente libera. Esse é o objetivo dos commits de marcação de versão. Se você tiver um problema com seu software em algum ambiente (produção ou outro), pode dizer com confiança que o problema foi introduzido pelo commit do qual o release foi derivado.

(É por isso que as pessoas falam sobre 'construções reproduzíveis': para que possam ter certeza de que seu processo de lançamento não está introduzindo novos bugs que não estavam presentes no ambiente de visualização / preparação e que, se tiverem um bug na produção, o mesmo binário está sendo executado em sua máquina quando eles vão depurá-lo.)

Não faz sentido marcar o segundo commit verde a partir da parte inferior (o filho verde do commit marcado como 'Only bugfixes!') Como 'v1.0' porque você não liberou esse commit para produção. Você liberou o commit no master. Você pode até ver que o fluxo git marcou isso como 'Tag 1.0'.

Lembre-se de que as tags têm um objetivo: encontrar facilmente confirmações. Você marca um commit como 'v1.0' para encontrar facilmente o que foi lançado como versão 1.0. Você não o marca por ter uma marca 'v1.0' em algum lugar da sua árvore de commit vagamente perto do commit que você realmente lançou.

Se você tiver problemas para encontrar as tags do seu ramo de desenvolvimento, esse é um problema totalmente separado. Corrija a ferramenta usada para encontrar tags. Ou melhor ainda: não use git-flow. Parece bom nesse diagrama por causa dos adoráveis ​​pontos coloridos e linhas bem definidas, mas, na realidade, parece uma rede insana e bagunçada de linhas e pontos coloridos.