Perché dovrei utilizzare i tag rispetto a rami di rilascio / beta per il controllo delle versioni?

Uso git da circa un anno e vorrei utilizzare la codifica per, beh, i commit di tag in diverse versioni. Ho trovato molte informazioni sui comandi da usare per lavorare con i tag, ma quello che mi piacerebbe sapere è perché usare il tagging se posso semplicemente creare un nuovo ramo chiamato 1.1.0e non devo offuscare la mia mente con un intero nuovo set di comandi git?

Devono esserci molte buone ragioni per etichettare piuttosto che ramificare, ma mi piacerebbe sapere quali sono questi vantaggi.

I tag vengono utilizzati principalmente per riferimento futuro alla versione specifica del progetto, contrassegnando un commit. Ovviamente puoi sempre usare i rami, ma se cambi molte versioni, ti ritroverai con molti rami inutilizzati o usati raramente.

In pratica, i tag sono comunque rami senza rami, aggiungendo semplicemente un modo per fare riferimento a una versione specifica del progetto per ridurre la complessità.

Modifica: ecco un bel modo per usare git che uso per tutti i miei progetti.

Un tag è immutabile .

Mentre puoi creare un ramo chiamato "1.0.0" - tu, o chiunque abbia i diritti di commit, puoi anche semplicemente eseguire il push a quel ramo (deliberatamente o meno) e cambiare il significato di 1.0.0.

Non puoi farlo con un tag, una volta creato un tag, il gioco è fatto; Il tag 1.0.0 significa esattamente questo e non può essere modificato ^* .

Questa è la principale differenza pratica tra un tag e un ramo

^* Puoi eliminare e ricreare un tag cambiando così un tag, ma certamente non per caso.

Tendo a utilizzare un flusso di lavoro che incorpora sia tag che rami. I tag sono utili per contrassegnare il codice rilasciato o build di sviluppo importanti. I rami sono utili per tenere traccia di tutte le modifiche relative a una versione specifica.

Ecco una buona recensione su questo tipo di flusso di lavoro: http://nvie.com/posts/a-successful-git-branching-model/

Branch e tag sono la stessa cosa (puntatore a un commit, anche noto come "ref" ), eccetto che branch si sposta automaticamente al commit successivo mentre il tag rimane per sempre ¹ sullo stesso commit.

Quando si crea una versione, in genere si desidera contrassegnare l '"istantanea" del codice da cui è stata creata quella versione e si desidera che rimanga contrassegnata in questo modo anche mentre si continua a sviluppare il codice, quindi è necessario utilizzare un tag.

Se hai provato a utilizzare un ramo per questo, potrebbe inavvertitamente passare a un commit diverso, da cui il rilascio non è stato creato.

¹ A meno che non elimini il tag, ovviamente.

NOTA: Mi rendo conto che questa è una vecchia domanda, ma ho sentito che la somiglianza (e una differenza cruciale) tra rami e tag non è stata approfondita in altre risposte con la massima chiarezza che avrebbe potuto essere.

Utilizzi i tag per annotare importanti commit nella cronologia. "Questo è stato il commit esatto che abbiamo utilizzato per questa versione quel giovedì piovoso quando il server di compilazione si è rotto". Se usi un ramo invece di un tag, non puoi mai sapere quale commit esatto hai usato. Sai solo "Abbiamo rilasciato la versione 1.1.0 da qualche parte su questo ramo", a meno che tu non annoti manualmente l'hash esatto per quel commit, motivo per cui usi i tag in primo luogo :)

Oltre alle altre risposte, ecco i miei 2 centesimi.

Risposta breve: utilizza i tag per le versioni di rilascio

Risposta lunga: credo che l'utilizzo di tag per il controllo delle versioni di rilascio in particolare sia migliore rispetto all'utilizzo di branch. Se è necessario aggiornare il rilascio, è sufficiente diramare il commit taggato e una volta terminato di lavorare su quel ramo (molto probabilmente un ramo di hotfix), creare un nuovo tag all'inizio di quel nuovo ramo con la nuova versione. Quindi, unisci nuovamente quel ramo in master / development perché non dovresti davvero cambiare una versione di rilascio a meno che non sia un hotfix che probabilmente dovrebbe essere unito di nuovo nel tuo codice sorgente. Quindi elimina quel ramo poiché non è più necessario. Se è necessario applicare un altro hotfix a quella nuova versione, ripetere gli stessi passaggi.

Fare riferimento alla sezione del seguente articolo che mostra come unire un hotfix con il flusso di lavoro Git dell'autore: https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2