Mostra su quale tag git sei?

216

Ho problemi a scoprire quale tag è attualmente estratto.

Quando io faccio:

git checkout tag1
git branch

Non riesco a scoprire su quale tag si trova. Registra solo:

* (no branch)
master

È possibile scoprire quali tag sono stati estratti? Nell'esempio sopra, questo sarebbe tag1.

git git-checkout git-tag

— grm
fonte

326

Modifica : Jakub Narębski ha più git-fu. Il seguente comando molto più semplice funziona perfettamente:

git describe --tags

(O senza il --tagsse hai estratto un tag annotato. Il mio tag è leggero, quindi ho bisogno dei tag -.)

segue la risposta originale:

git describe --exact-match --tags $(git log -n1 --pretty='%h')

Qualcuno con più git-fu potrebbe avere una soluzione più elegante ...

Questo sfrutta il fatto che git-logriporta il registro a partire da ciò che hai estratto. %hstampa l'hash abbreviato. Quindi git describe --exact-match --tagstrova il tag (leggero o annotato) che corrisponde esattamente a quel commit.

La $()sintassi sopra presuppone che tu stia usando bash o simili.

— bstpierre
fonte

22

Il solo utilizzo git describemostrerebbe il nome del tag se si è esattamente sul tag (annotato) o, in <tag>-<n>-g<shortened sha-1>caso contrario, dov'è il <n>numero di commit da allora <tag>.

— Jakub Narębski,

1

@Jakub - Grazie. Ho aggiunto --exact-matchalla mia risposta pochi secondi prima del tuo commento. Bello sapere che puoi rimuoverlo e ottenere comunque buone informazioni dall'input fuzzier.

— bstpierre,

Grazie, era esattamente quello che stavo cercando. A proposito, anche git-descrive --exact-match (senza --tags) funziona per me.

— gr

3

Usare git rev-parse HEADè una soluzione migliore di git log -n1 --pretty='%h'... ma perché non puoi semplicemente scrivere HEAD(o niente, come git describeimpostazione predefinita su HEAD)?

— Jakub Narębski,

solo Guybrush odia la porcellana

— vdegenne,

71

Questo ha funzionato per me git describe --tags --abbrev=0

— MK
fonte

2

Sì. funziona anche se non sei esattamente su quel tag! :)

— Martin Muzatko,

13

Uhhh. ... Se esegui il checkout dell'hash tre commit dopo il tag, non sei "su quel tag". Ti dice l'ultimo tag prima o al commit che è stato estratto. Quindi questo non è corretto.

— inghehere

Funziona anche su Windows :)

— cowlinator

51

Mostra tutti i tag sull'attuale HEAD (o commit)

git tag --points-at HEAD

— George Pavelka
fonte

1

Si noti che questo comando non segnala un errore nella riga di comando anche se il risultato risulta vuoto. Bug? Restituisce anche un elenco se ci sono più tag in quella posizione. È la risposta migliore ma gli scripter dovrebbero procedere con cautela tenendo presente queste avvertenze.

— inghehere

Seguendo il commento di @ ingyhere. Sì, è una buona informazione che non ha un errore e le persone devono gestire il risultato di conseguenza. Ma non lo definirei un bug. Nel mio caso, "vuoto se non ci sono tag" è valido. Altri casi, qualcuno può salvarlo in una variabile, quindi controllare se è vuoto (link alle istruzioni bash)

— driftcatcher

23

git describeè un comando di porcellana , che dovresti evitare:

http://git-blame.blogspot.com/2013/06/checking-current-branch-programatically.html

Invece, ho usato:

git name-rev --tags --name-only $(git rev-parse HEAD)

— Greg
fonte

11

Sta tornando "indefinito"

— Straniero

4

Questo genera un trailing ^0per i commit che corrispondono ai tag (ad es. Per i tag 1.0in output 1.0^0). Esiste un modo per avere solo l'output di Git 1.0o dovrei usare sed per questo?

— Daniel Serodio,

13

Solo qualche pignolo concettuale: penso che tu abbia invertito i significati di porcellana e idraulica. Va bene usare la porcellana, è di alto livello e pensato per un uso normale . L'impianto idraulico è interno (come suggerisce il nome) e non è consigliato solo perché gli sviluppatori git si riservano il diritto di modificare i propri argomenti e l'output senza preavviso. Quindi il tuo primo suggerimento è in realtà quello leggermente più appropriato.

— Leo Antunes,

5

L'articolo collegato dice di evitare l'uso di "git branch" perché non funziona per questo caso d'uso. Non riesco a pensare a nessuna buona ragione per evitare di usare Git Descr. Come dice Leo, i comandi "Porcellana" sono i comandi che dovresti generalmente usare. Evita i comandi idraulici se non sai davvero cosa stai facendo. "git descritto" funziona alla grande.

— Danny,

4

I comandi "Porcelain" sono quelli che dovresti usare, non quelli che dovresti evitare. Sono i comandi il cui output è leggibile dalla macchina e non cambieranno nelle versioni future, quindi possono essere utilizzati in script ecc. I comandi non di porcellana tendono a produrre un output più leggibile dall'uomo, ma possono cambiare nelle versioni future, ad es. Per renderlo più leggibile, non perché qualcosa di importante è effettivamente cambiato.

— rjmunro,

22

Quando controlli un tag, hai quella che viene chiamata "testa staccata" . Normalmente, il commit HEAD di Git è un puntatore al ramo che hai attualmente estratto. Tuttavia, se controlli qualcosa di diverso da un ramo locale (un tag o un ramo remoto, ad esempio) hai una "testa staccata" - non sei davvero su nessun ramo. Non dovresti fare alcun commit mentre sei su una testa staccata.

Va bene controllare un tag se non si desidera apportare modifiche. Se stai solo esaminando il contenuto dei file o vuoi costruire il tuo progetto da un tag, va bene git checkout my_tage lavora con i file, purché non ti impegni . Se si desidera iniziare a modificare i file, è necessario creare un ramo basato sul tag:

$ git checkout -b my_tag_branch my_tag

creerà un nuovo ramo chiamato a my_tag_branchpartire da my_tag. È possibile eseguire il commit delle modifiche in questo ramo.

— mipadi
fonte

1

Risposta fantastica.

— Panos Filianos

9

git log --decorate

Questo ti dirà quali riferimenti indicano il commit attualmente estratto.

— chriswatrous
fonte