Un ramo di rilascio o il ramo principale devono essere taggati quando si usa gitflow?

Questo problema indica che:

Da quanto ho capito, posizionare il tag sul ramo di rilascio prima della fusione (e non sul ramo principale) è in effetti la cosa giusta da fare, in modo che possa essere trovato da git descrivere anche i tag dal ramo di sviluppo. Vedi # 374

mentre un altro post :

Ho installato accidentalmente la versione 0.4.2-pre tramite homebrew oggi e sono stato confuso dal modo in cui funziona il tagging in quella versione. In precedenza (versione 0.4.1) il tag era stato creato sul ramo principale, dopo che il ramo di rilascio era stato unito in esso. Ora sembra che il tag sia stato creato sull'ultimo commit del ramo di rilascio, che non sembra essere una buona idea per me. Soprattutto se si dispone di un sistema di compilazione che si basa su tag git e crea una versione di rilascio se HEAD è un commit con tag e una versione di sviluppo se è uno dei seguenti commit. Qualcuno potrebbe spiegarmi la logica dietro questo cambiamento? E per quanto riguarda il versioning semantico, non lo considero un aumento della versione a livello di patch!

Nel nostro team abbiamo avuto e discusso più volte al riguardo. Alcuni indicano che è necessario creare un tag dal ramo principale, mentre altri preferiscono il ramo di rilascio. Secondo l'immagine di gitflow:

sembra che il tag sia posizionato sul master.

Innanzitutto, non puoi taggare i rami, puoi solo taggare i commit.

Dovresti taggare il commit che effettivamente rilasci. Questo è il punto del commit della codifica della versione. Se si riscontra un problema con il software in un ambiente (produzione o altro), è possibile affermare con certezza che il problema è stato introdotto dal commit da cui deriva quella versione.

(Questo è il motivo per cui le persone parlano di "build riproducibili": quindi possono essere sicuri che il loro processo di rilascio non introduca nuovi bug che non erano presenti nel loro ambiente di anteprima / messa in scena e che se hanno un bug in produzione lo stesso binary è in esecuzione sul loro computer quando vanno a eseguire il debug.)

Non ha senso contrassegnare il secondo commit verde dal basso (il figlio verde del commit contrassegnato come "Solo correzioni di bug!") Come "v1.0" perché non è stato rilasciato quel commit in produzione. Hai rilasciato il commit sul master. Puoi persino vedere che git flow lo ha contrassegnato come 'Tag 1.0'.

Ricorda, i tag hanno uno scopo: trovare facilmente commit. È possibile contrassegnare un commit come 'v1.0' in modo da poter trovare facilmente la cosa rilasciata come versione 1.0. Non lo metti in tag per avere un tag 'v1.0' da qualche parte nella tua struttura di commit vagamente vicino al commit che hai effettivamente rilasciato.

Se hai problemi a trovare i tag dal tuo ramo di sviluppo, questo è un problema completamente separato. Correggi lo strumento che usi per trovare i tag. O meglio ancora: non usare git-flow. Sembra carino in quel diagramma a causa dei bei punti colorati e delle linee ben disposte, ma in realtà sembra una rete disordinata e disordinata di linee e punti colorati.