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 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.4L'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.
materiale correlato
Scheda di riferimento rapido di Git
Scopri la soluzione
Impara a utilizzare Git con Bitbucket Cloud
Tag leggeri
git tag v1.4-lwL'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 tagVerrà 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-rc2Per 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.3Questo 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 existsInoltre, 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.4Per 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.4Il 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
v3In 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.
Blog di Bitbucket
Percorso di apprendimento DevOps
