Se un ramo di rilascio o il ramo master viene taggato quando viene utilizzato gitflow?

Question

Se un ramo di rilascio o il ramo master viene taggato quando viene utilizzato gitflow?

#1 da (10 voti)

11

From my understanding placing the tag on the release branch before merging (and not on the master branch) is in fact the correct thing to do so it can be found by git describe --tags from the develop branch, too. See #374

mentre altro post :

I accidentally installed the 0.4.2-pre version via homebrew today and was confused by the way the tagging works in that version. Previously (version 0.4.1) the tag was created on the master branch, after the release branch has been merged into it. Now it seems that the tag is created on the last commit of the release branch, which seems not to be a good idea for me. Especially if you have a build-system that relies on git tags and creates a release version if HEAD is a tagged commit and a development version if its one of the following commits. Could someone explain the logic behind this change to me? And with respect to semantic versioning I don't would consider this to be a version bump in the patch-level!

Nel nostro team abbiamo e avuto più discussioni su questo. Alcuni indicano che è necessario creare un tag dal ramo master mentre altri preferiscono il ramo di rilascio. Secondo l'immagine gitflow:

sembra che il tag sia posizionato sul master.

gitflow

posta 030 21.04.2017 - 11:56

fonte

1 risposta

Leggi altre domande sui tag gitflow

Memorizzazione di dati n-grammi In quali modi significativi Erlang previene le condizioni di gara nella programmazione concorrente?

score 10 · Accepted Answer

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

Dovresti taggare il commit che hai effettivamente rilasciato. Questo è il punto in cui il tagging della versione si impegna. Se si verifica un problema con il software in un determinato ambiente (produzione o altro), è possibile affermare con certezza che il problema è stato introdotto dal commit da cui è stata derivata tale versione.

(Questo è il motivo per cui le persone parlano di "build riproducibili": quindi possono essere certi che il loro processo di rilascio non introduca nuovi bug che non erano presenti nell'ambiente di anteprima / staging e che se hanno un bug in produzione lo stesso binario è in esecuzione sul loro computer quando eseguono il debug.)

Non c'è nessun punto che codifica il secondo commit verde dal basso (il figlio verde del commit ha segnato "Solo correzioni!") come "v1.0" perché non hai rilasciato quel commit alla produzione. Hai rilasciato il commit sul master. Puoi persino vedere che il flusso git lo ha contrassegnato come "Tag 1.0".

Ricorda che i tag hanno uno scopo: trovare facilmente i commit. Tagga un commit come 'v1.0' in modo da poter trovare facilmente la cosa che hai rilasciato come versione 1.0. Non taggalo per il fatto di avere un tag "v1.0" da qualche parte nel tuo albero di commit vagamente vicino al commit che hai effettivamente rilasciato.

Se riscontri problemi nel trovare i tag dal tuo ramo di sviluppo, si tratta di un problema completamente separato. Correggi lo strumento che utilizzi per trovare i tag. O meglio ancora: non usare git-flow. È bello in quel diagramma grazie ai bei punti colorati e alle linee ben disegnate, ma in realtà sembra una folle rete di linee e punti colorati.