Git tag

Questo documento discuterร  il concetto di utilizzo di tag e il comando git tag. I tag sono riferimenti che rimandano a punti specifici nella cronologia Git. Vengono generalmente utilizzati per acquisire un punto cronologico che viene utilizzato per una versione contrassegnata (ad es. v1.0.1).

Un tag รจ come un branch che non cambia. A differenza dei branch, i tag, dopo essere stati creati, non hanno un'ulteriore cronologia di commit. Per maggiori informazioni sui branch, visita la pagina dei branch git.

Questo documento tratterร  i diversi tipi di tag, come crearli, elencarli, eliminarli, usare comandi come git checkout tag per visualizzare un commit con tag e git push tag per condividere tag con altre persone.

Come creare un tag in Git

Per creare un nuovo tag, esegui il seguente comando:

git tag <tagname>

Sostituisci <nometag> con un identificatore semantico dello stato del repository al momento della creazione del tag. Uno schema comune consiste nell'usare numeri di versione come git tag v1.4. Git supporta due diversi tipi di tag, tag annotati eย tag leggeri. L'esempio precedente ha creato un tag leggero. I tagย leggeri e i tag annotati differiscono nella quantitร  di metadati di accompagnamento cheย archiviano. Una best practice consiste nel considerare i tag annotati come pubblici e i tag leggeri come privati. I tag annotati memorizzano metadati aggiuntivi come: il nome del tagger,ย l'email e la data. Si tratta di dati importanti per un rilascio pubblico. I tag leggeriย sono essenzialmente dei ยซsegnalibriยป per un commit, sono semplicemente un nome e un puntatore a unย commit, utili per creare collegamenti rapidi ai commit pertinenti.

Tag annotati

I tag annotati sono archiviati come oggetti completi nel database Git. Come giร  detto, memorizzano metadati aggiuntivi come: il nome del tagger, l'email e la data. In modo simile ai commit e ai messaggi di commit, i tag annotati hanno un messaggio di codifica. Inoltre, per motivi di sicurezza, i tag annotati possono essere firmati e verificati con GNU Privacy Guard (GPG). Le best practice suggerite per i tag git consistono nel preferire i tag annotati a quelli leggeri in modo da poter avere tutti i metadati associati.

git tag -a v1.4

L'esecuzione di questo comando creerร  un nuovo tag annotato identificato con v1.4. Il comando aprirร  quindi l'editor di testo predefinito configurato per richiedere un ulteriore inserimento di metadati.

git tag -a v1.4 -m "my version 1.4"

L'esecuzione di questo comando รจ simile alla chiamata precedente, tuttavia, a questa versione del comando vengono passati l'opzione -m e un messaggio. Si tratta di un metodo pratico simile a git commit -m che creerร  immediatamente un nuovo tag senza aprire l'editor di testo locale per salvare il messaggio passato con l'opzione -m.

Tag leggeri

git tag v1.4-lw

L'esecuzione di questo comando crea un tag leggero identificato come v1.4-lw. I tag leggeri vengono creati senza le opzioni -a, -s o -m. I tag leggeri creano un nuovo checksum del tag e lo memorizzano nella directory .git/ del repository del progetto.

Elenco dei tag

Per elencare i tag archiviati in un repository, esegui quanto segue:

git tag

Verrร  visualizzato un elenco di tag:

v0.10.0
    v0.10.0-rc1
    v0.11.0
    v0.11.0-rc1
    v0.11.1
    v0.11.2
    v0.12.0
    v0.12.0-rc1
    v0.12.1
    v0.12.2
    v0.13.0
    v0.13.0-rc1
    v0.13.0-rc2

Per perfezionare l'elenco dei tag, l'opzione -l puรฒ essere passata con un'espressione jolly:

$ git tag -l *-rc*
    v0.10.0-rc1
    v0.11.0-rc1
    v0.12.0-rc1
    v0.13.0-rc1
    v0.13.0-rc2
    v0.14.0-rc1
    v0.9.0-rc1
    v15.0.0-rc.1
    v15.0.0-rc.2
    v15.4.0-rc.3

Questo esempio precedente utilizza l'opzione -l e un'espressione jolly -rc che restituisce un elenco di tutti i tag contrassegnati dal prefisso -rc, tradizionalmente utilizzati per identificare i candidati al rilascio.

Applicazione di tag ai vecchi commit

I precedenti esempi di tag hanno dimostrato le operazioni sui commit impliciti. Per impostazione predefinita, git tag creerร  un tag sul commit a cui HEAD fa riferimento. In alternativa, git tag puรฒ essere passato come riferimento a un commit specifico. Questa operazione taggherร  il commit passato anzichรฉ impostarlo come predefinito su HEAD. Per raccogliere un elenco di commit piรน vecchi, esegui il comando git log.

$ git log --pretty=oneline
    15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'feature'
    a6b4c97498bd301d84096da251c98a07c7723e65 add update method for thing
    0d52aaab4479697da7686c15f77a3d64d9165190 one more thing
    6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiment'

L'esecuzione di git log produrrร  un elenco di commit. In questo esempio selezioneremo la ยซfunzioneยป di unione dei branch di commit piรน importante per il nuovo taggare. Dovremo fare riferimento all'hash SHA del commit da passare a Git:

git tag -a v1.2 15027957951b64cf874c3557a0f3547bd83b3ff6

L'esecuzione della chiamata git tag sopra riportata creerร  un nuovo commit annotato identificato come v1.2 per il commit selezionato nel precedente esempio di git log.

Nuova applicazione/sostituzione dei vecchi tag

Se provi a creare un taggare con lo stesso identificatore di un tag esistente, Git genererร  un errore simile al seguente:

fatal: tag 'v0.4' already exists

Inoltre, se provi a taggare un vecchio commit con un identificatore di tag esistente, Git genererร  lo stesso errore.

Nel caso in cui tu debba aggiornare un tag esistente, deve essere utilizzata l'opzione -f FORCE.

git tag -a -f v1.4 15027957951b64cf874c3557a0f3547bd83b3ff6

L'esecuzione del comando precedente mapperร  il commit 15027957951b64cf874c3557a0f3547bd83b3ff6 sull'identificatore tag v1.4. Sostituirร  qualsiasi contenuto esistente per il tag v1.4.

Condivisione: esecuzione del push dei tag al remoto

La condivisione dei tag รจ simile al push dei branch. Per impostazione predefinita, git push non eseguirร  il push di tag. I tag devono essere passati esplicitamente a git push.

$ git push origin v1.4
    Counting objects: 14, done.
    Delta compression using up to 8 threads.
    Compressing objects: 100% (12/12), done.
    Writing objects: 100% (14/14), 2.05 KiB | 0 bytes/s, done.
    Total 14 (delta 3), reused 0 (delta 0)
    To git@bitbucket.com:atlasbro/gittagdocs.git
     * [new tag]         v1.4 -> v1.4

Per eseguire il push di piรน tag contemporaneamente, passa l'opzione --tags al comando git push. Quando un altro utente clona o estrae un repository, riceverร  i nuovi tag.

Checkout dei tag

Puoi visualizzare lo stato di un repository in un tag usando il comando git checkout.

git checkout v1.4

Il comando precedente eseguirร  il checkout del tag v1.4. Questo porrร  il repository in uno stato HEAD distaccato. Ciรฒ significa che qualsiasi modifica apportata non aggiornerร  il tag. Verrร  creato un nuovo commit distaccato, che non farร  parte di alcun branch e sarร  raggiungibile direttamente solo dall'hash SHA dei commit. Pertanto รจ consigliabile creare un nuovo branch ogni volta che si apportano modifiche in uno stato HEAD distaccato.

Eliminazione dei tag

L'eliminazione dei tag รจ un'operazione semplice. Passare l'opzione -d e un identificatore di tag a git tag eliminerร  il tag identificato.

$ git tag
    v1
    v2
    v3
    $ git tag -d v1
    $ git tag
    v2
    v3

In questo esempio, git tag viene eseguito per visualizzare un elenco di tag che mostrano v1, v2, v3, quindi viene eseguito git tag -d v1 che elimina il tag v1.

Riepilogo

Ricapitolando, i tag sono un meccanismo aggiuntivo utilizzato per creare un'istantanea di un repository Git. Vengono solitamente utilizzati per creare tag identificativi semantici del numero di versione che corrisponde ai cicli di rilascio del software. Il comando Git tag รจ lo strumento principale per i tag: creazione, modifica ed eliminazione. Esistono due tipi di tag: annotati e leggeri. I tag annotati sono generalmente i migliori, in quanto memorizzano importanti metadati aggiuntivi sul tag. I comandi Git aggiuntivi trattati in questo documento sono Git push e Git checkout.ย Visita le pagine corrispondenti che ne illustrano l'uso esteso.

Consigliata per te

Blog di Bitbucket

Percorso di apprendimento DevOps

Scopri di piรน su Git

Trova altre guide e risorse su Git in questo hub.