Close

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, condividerli e altro ancora.


Creazione di un tag


Per creare un nuovo tag, esegui il seguente comando:

git tag <tagname>

Sostituisci 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.

Logo Git
materiale correlato

Scheda di riferimento rapido di Git

Logo di Bitbucket
Scopri la soluzione

Impara a utilizzare Git con Bitbucket Cloud

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é essere 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.


Condividi l'articolo
Argomento successivo

Letture consigliate

Aggiungi ai preferiti queste risorse per ricevere informazioni sui tipi di team DevOps e aggiornamenti continui su DevOps in Atlassian.

Le persone collaborano utilizzando una parete piena di strumenti

Blog di Bitbucket

Illustrazione su Devops

Percorso di apprendimento DevOps

Funzione Demo Den per demo con esperti Atlassian

Come Bitbucket Cloud funziona con Atlassian Open DevOps

Iscriviti alla nostra newsletter DevOps

Thank you for signing up