guides

Un tag Git è un riferimento con nome che punta a un commit specifico di un repository. Mentre un commit è identificato da un lungo hash difficile da ricordare, un tag dà a quel punto esatto della cronologia un nome breve e leggibile. I tag si usano più spesso per marcare punti di release, così che un nome come v1.0.0 si riferisca allo stato preciso del codice rilasciato come quella versione.

La differenza fondamentale tra un tag e un ramo è che un tag non si muove. Un ramo è un puntatore che avanza ogni volta che vi aggiungi un nuovo commit, seguendo sempre il lavoro più recente. Un tag è fisso: una volta associato a un commit, continua a puntare a quello stesso commit anche se lo sviluppo prosegue oltre. È esattamente ciò che si vuole per una release, perché il significato di v1.0.0 non dovrebbe mai cambiare dopo la sua pubblicazione.

Tag leggeri contro tag annotati

Git supporta due tipi di tag: i tag leggeri e i tag annotati. Un tag leggero è poco più di un nome che punta direttamente a un commit, senza informazioni aggiuntive memorizzate accanto. È rapido da creare e funziona bene come segnalibro personale, ma non conserva alcuna traccia di chi lo ha creato né del perché.

Un tag annotato è memorizzato come un oggetto completo nel database di Git. Registra il nome della persona che ha creato il tag, la data di creazione e un messaggio di tag, più o meno come un commit registra il proprio autore e il proprio messaggio. I tag annotati possono anche essere firmati con GPG, il che consente ad altri di verificare che un tag di release provenga davvero da te. Per le release pubbliche, i tag annotati sono generalmente la scelta consigliata per via di questi metadati aggiuntivi e della possibilità di firmarli.

Creare e inviare i tag

Creare i tag è semplice. Eseguire git tag con un nome e senza altre opzioni crea un tag leggero sul commit corrente. Aggiungere l'opzione -a, come in git tag -a v1.0.0 -m 'Release 1.0.0', crea un tag annotato con un messaggio. Puoi anche taggare un commit più vecchio passando il suo hash alla fine del comando, il che è utile quando ti accorgi solo in seguito che un commit particolare era il vero punto di release.

• Un tag nomina un commit specifico; a differenza di un ramo, non si muove una volta impostato.
• Tag leggero: solo un nome che punta a un commit, senza metadati aggiuntivi.
• Tag annotato: un oggetto completo che memorizza autore, data e messaggio, e può essere firmato con GPG.
• Si crea con git tag v1.0.0 (leggero) o git tag -a v1.0.0 -m '...' (annotato).
• I tag non vengono inviati per impostazione predefinita: mandali con git push origin <tag> o git push --tags.
• I tag marcano le release, spesso come SemVer vX.Y.Z, e attivano spesso CI/CD e pagine di release.

Un aspetto che sorprende i principianti è che i tag non vengono condivisi automaticamente. Quando esegui git push, i tuoi rami vengono aggiornati sul remoto, ma i tuoi tag restano locali a meno che tu non li invii esplicitamente. Invii un singolo tag con git push origin seguito dal nome del tag, oppure mandi tutti i tuoi tag in una volta con git push --tags. Dimenticare questo passaggio è un motivo frequente per cui un tag di release compare sulla macchina di uno sviluppatore ma manca nel repository condiviso.

Tag, versionamento e automazione delle release

I tag si inseriscono naturalmente in uno schema di versioni. Molti progetti seguono il versionamento semantico, in cui una versione ha la forma MAJOR.MINOR.PATCH, e ogni release è catturata da un tag corrispondente come v2.4.1. Poiché il tag è immutabile, chiunque può in seguito estrarre quel tag esatto e ricostruire il codice così com'era per quella versione, il che costituisce la base delle release riproducibili.

I tag alimentano anche buona parte dell'automazione. Le pipeline di integrazione e distribuzione continue sono spesso configurate per attivarsi quando viene inviato un nuovo tag, così che taggare un commit come v1.2.0 compili, testi e pubblichi automaticamente quella versione. Le piattaforme che ospitano repository trasformano spesso i tag in pagine di release, allegando note e artefatti scaricabili a ogni versione taggata. In questo modo un piccolo puntatore immutabile diventa l'ancora di un intero processo di release.

Lavorare con i tag in sicurezza

Poiché un tag è solo un riferimento, è economico e sicuro da usare. Elencare i tag, ispezionare ciò che dice un tag annotato o estrarre il codice a un dato tag sono tutte operazioni di sola lettura che non disturbano il lavoro in corso. Eliminare un tag localmente è altrettanto semplice, ma eliminare un tag già inviato e usato da altri va fatto con cautela, poiché persone e pipeline potrebbero già dipenderne.

In sintesi

In breve, un tag Git è un'etichetta stabile su un momento della cronologia del tuo progetto. I tag leggeri sono rapidi segnaposto personali, mentre i tag annotati portano una paternità, un messaggio e firme opzionali che li rendono adatti alle release pubbliche. Combinati con uno schema di versioni e inviati al remoto condiviso, i tag trasformano un hash di commit impossibile da memorizzare in un riferimento duraturo e verificabile per una versione specifica del tuo software.