¿Mostrar en qué etiqueta de git estás?

216

Tengo problemas para averiguar qué etiqueta está actualmente desprotegida.

Cuando lo hago:

git checkout tag1
git branch

Parece que no puedo descubrir en qué etiqueta estoy. Solo registra:

* (no branch)
master

¿Es posible averiguar qué etiquetas están desprotegidas? En el ejemplo anterior, esto sería tag1.

git git-checkout git-tag

— grm
fuente

326

Editar : Jakub Narębski tiene más git-fu. El siguiente comando mucho más simple funciona perfectamente:

git describe --tags

(O sin el --tagssi ha extraído una etiqueta anotada. Mi etiqueta es liviana, así que necesito las etiquetas -).

La respuesta original sigue:

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

Alguien con más git-fu puede tener una solución más elegante ...

Esto aprovecha el hecho de que git-loginforma el registro a partir de lo que ha desprotegido. %himprime el hash abreviado. Luego git describe --exact-match --tagsencuentra la etiqueta (ligera o anotada) que coincide exactamente con esa confirmación.

La $()sintaxis anterior supone que está utilizando bash o similar.

— bstpierre
fuente

22

Solo git describeusaría mostraría el nombre de la etiqueta si está exactamente en la etiqueta (anotada), o <tag>-<n>-g<shortened sha-1>si no, dónde <n>está el número de confirmaciones desde entonces <tag>.

— Jakub Narębski el

1

@Jakub - Gracias. Agregué --exact-matcha mi respuesta segundos antes de tu comentario. Es bueno saber que puede eliminarlo y aún así obtener buena información de la entrada más difusa.

— bstpierre

Gracias, esto era exactamente lo que estaba buscando. Por cierto, incluso git-describe --exact-match (sin --tags) funciona para mí.

— grm

3

Usar git rev-parse HEADes una solución mejor que git log -n1 --pretty='%h'... pero ¿por qué no puedes simplemente escribir HEAD(o nada, como git describepredeterminado en HEAD)?

— Jakub Narębski

solo Guybrush odia la porcelana

— vdegenne

71

Esto funciono para mi git describe --tags --abbrev=0

— MK
fuente

2

Si. ¡Esto funciona incluso si no estás exactamente en esa etiqueta! :)

— Martin Muzatko

13

Uhhh ... Si comprueba el hash tres confirmaciones después de la etiqueta, no está "en esa etiqueta". Te dice la última etiqueta antes o en el commit que está desprotegido. Entonces esto es incorrecto.

— ingyhere

También funciona en Windows :)

— cowlinator

49

Mostrar todas las etiquetas en HEAD actual (o commit)

git tag --points-at HEAD

— George Pavelka
fuente

1

Tenga en cuenta que este comando no informa un error en la línea de comandos, incluso si el resultado aparece vacío. ¿Insecto? También devuelve una lista si hay varias etiquetas en esa ubicación. Es la mejor respuesta, pero los scripters deben proceder con precaución teniendo en cuenta estas advertencias.

— ingyhere

Siguiendo el comentario de @ ingyhere. Sí, es buena información que no tiene un error, y las personas deben manejar el resultado en consecuencia. Pero no lo llamaría un error. Para mi caso, "vacío si no hay etiquetas" es válido. En otros casos, alguien puede guardarlo en una variable y luego verificar si está vacío (enlace a las instrucciones de bash)

— driftcatcher

23

git describees un comando de porcelana , que debes evitar:

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

En cambio, usé:

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

— Greg
fuente

11

Está volviendo "indefinido"

— Extraño

44

Esto genera un seguimiento ^0para las confirmaciones que corresponden a etiquetas (por ejemplo, para la etiqueta 1.0que genera 1.0^0). ¿Hay alguna manera de tener solo la salida de Git 1.0, o debería usar sed para esto?

— Daniel Serodio

13

Solo un poco conceptual: creo que invertiste los significados de porcelana y plomería. Está bien usar porcelana, es de alto nivel y está diseñado para un uso normal . La fontanería es interna (como su nombre lo indica) y solo no se recomienda porque los desarrolladores de git se reservan el derecho de cambiar sus argumentos y resultados sin previo aviso. Entonces, su primera sugerencia es en realidad la más adecuada.

— Leo Antunes

55

El artículo vinculado dice que se evite el uso de "git branch" porque no funciona para este caso de uso. No se me ocurre ninguna buena razón para evitar usar git describe. Como dice Leo, los comandos de "Porcelana" son los que generalmente se supone que debes usar. Evite los comandos de plomería a menos que realmente sepa lo que está haciendo. "git describe" funciona muy bien.

— Danny

44

Los comandos de "Porcelana" son los que debe usar, no los que debe evitar. Son los comandos cuya salida es legible por máquina y no cambiará en futuras versiones, por lo que se puede confiar en ellos en scripts, etc. legible, no porque algo importante haya cambiado realmente.

— rjmunro

22

Cuando revisa una etiqueta, tiene lo que se llama una "cabeza separada" . Normalmente, la confirmación HEAD de Git es un puntero a la rama que actualmente ha desprotegido. Sin embargo, si revisa algo que no sea una sucursal local (una etiqueta o una sucursal remota, por ejemplo), tiene una "cabeza separada": no está realmente en ninguna sucursal. No debe realizar ningún compromiso mientras está con la cabeza separada.

Está bien revisar una etiqueta si no desea realizar ninguna edición. Si solo está examinando el contenido de los archivos, o si desea construir su proyecto a partir de una etiqueta, está bien git checkout my_tagy trabajar con los archivos, siempre y cuando no realice ninguna confirmación . Si desea comenzar a modificar archivos, debe crear una rama basada en la etiqueta:

$ git checkout -b my_tag_branch my_tag

creará una nueva rama llamada a my_tag_branchpartir de my_tag. Es seguro realizar cambios en esta rama.

— mipadi
fuente

1

Fantástica respuesta.

— Panos Filianos

9

git log --decorate

Esto le dirá qué referencias apuntan al commit actualmente desprotegido.

— chriswatrous
fuente