Guide galattiche per aspiranti programmatori

Git permette di aggiungere un tag a uno specifico commit, in modo da poter usare tale tag come riferimento per uno specifico punto nella history del repository. Utilizzo tipico dei tag è quello di contrassegnare un determinato rilascio o versione, per poter in un secondo momento accedervi con semplicità. A differenza dei branch, infatti, una volta creato un tag non vengono “aggiunti” i nuovi successivi commit al tag.

Il comando che permette di gestire i tag Git è git tag, vediamone alcuni usi.

git tag <TAG_NAME>

Associa al commit attualmente estratto nella working copy il tag con nome TAG_NAME.

Non avendo specificato alcuna opzione, Git creerà un tag lightweight, ovvero un tag senza particolari metadati aggiunti (ad esempio. chi ha creato il tag). I tag lightweight sono essenzialmente dei “segnalibri” per singoli commit, è buona pratica non usarli per contrassegnare rilasci pubblici, ma usarli solo localmente per contrassegnare particolari commit ritenuti importanti in fase di sviluppo.

git tag -a <TAG_NAME>

Crea un tag annotated, cioè oltre al nome fornito per il tag Git salverà nel repository metadati aggiuntivi come nome ed email di chi ha creato il tag, data, …

Nel momento in cui si crea un tag annotated, come per i commit, viene richiesto un messaggio, che può essere fornito direttamente con il comando tramite l’opzione -m "messaggio del tag"

$ git tag
1.0.0
1.0.1
1.0.2
1.0.3
1.0.4
1.1.1-alpha
...
$ git tag -l "*beta*"
v1.1.1-beta
v1.1.1-beta2
v1.1.1-beta3

Se eseguito senza alcuna opzione, il comando git tag mostra i tag attualmente presenti nel repository. È possibile filtrare solo i tag contenenti una determinata espressione usando l’opzione -l e una espressione con wildcard.

$ git tag -a v1.2.0 0d52aaab4479697da7686c15f77a3d64d9165190

Aggiungendo l’id di un commit al comando usato per creare un tag, il tag verrà applicato al commit indicato invece che a quello corrente.

$ git tag -d <TAG_NAME>

L’opzione -d permette di rimuovere uno specifico tag esistente.

$ git tag
v1
v1.0.0
$ git add package.json
$ git commit -m "release version 1.1.0"
$ git tag v1.1.0 -m "tagging version 1.1.0"
$ git tag -f v1 -m "moving tag v1 to latest release"

È ovviamente possibile avere più tag per ogni commit, così come, nel caso sia necessario, “spostare” un tag esistente da un commit a un’altro. Nei comandi indicati nell’esempio qui sopra supponiamo infatti che esista un commit che è stato precedentemente taggato con i tag v1.0.0 (la versione esatta) e un generico v1 (ovvero un tag che indica l’ultimo rilascio della versione “1” del progetto). Nel momento in cui rilasciamo la versione 1.1.0 possiamo creare un nuovo tag sul nuovo commit per la versione specifica v1.1.0 e forzare l’update del tag esistente v1 in modo che punti anch’esso all’ultimo commit appena creato. Notare che queste convenzioni sono di progetto e non di Git.

Un’ ultima annotazione: come ogni altro riferimento a commit nella history, Git permette di usare il nome di un tag in molti altri comandi, ad esempio:

• git checkout v1.3.0 – esegue il checkout del commit taggato come v1.3.0
• git diff v1.1.1-beta..v1.1.1-beta2 mostra il diff tra due tag esistenti