Mostrar em qual tag git você está?

216

Estou tendo problemas para descobrir qual tag está com check-out no momento.

Quando eu faço:

git checkout tag1
git branch

Não consigo descobrir em qual etiqueta estou. Ele registra apenas:

* (no branch)
master

É possível descobrir quais tags estão com check-out? No exemplo acima, isso seria tag1.

git git-checkout git-tag

— grm
fonte

326

Edit : Jakub Narębski tem mais git-fu. O seguinte comando muito mais simples funciona perfeitamente:

git describe --tags

(Ou sem o --tagsse você fez check-out de uma tag anotada. Minha tag é leve, então preciso das tags -.)

resposta original a seguir:

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

Alguém com mais git-fu pode ter uma solução mais elegante ...

Isso aproveita o fato de que git-logrelata o log a partir do que você fez check-out. %himprime o hash abreviado. Em seguida, git describe --exact-match --tagslocaliza a tag (leve ou anotada) que corresponde exatamente a essa confirmação.

A $()sintaxe acima pressupõe que você esteja usando o bash ou similar.

— bstpierre
fonte

22

Apenas o uso git describemostraria o nome da tag se você estiver exatamente na tag (anotada) ou, <tag>-<n>-g<shortened sha-1>se não estiver, onde <n>está o número de confirmações desde<tag> .

— Jakub Narębski

1

@ Jakub - Obrigado. Eu adicionei --exact-matchà minha resposta segundos antes do seu comentário. É bom saber que você pode removê-lo e ainda obter boas informações de entradas mais difusas.

— bstpierre

Obrigado, era exatamente isso que eu estava procurando. Aliás, até o git-description --exact-match (sem --tags) funciona para mim.

— GRM

3

Usar git rev-parse HEADé uma solução melhor do que git log -n1 --pretty='%h'... mas por que você não pode simplesmente escrever HEAD(ou nada, como git describepadrão no HEAD)?

— Jakub Narębski

somente Guybrush odeia porcelana

— vdegenne

71

Isso funcionou para mim git describe --tags --abbrev=0

— MK
fonte

2

Sim. isso funciona mesmo se você não estiver exatamente nessa tag! :)

— Martin Muzatko

13

Uhhh ... Se você efetuar o check-out dos três hash confirmados após a tag, você não estará "nessa tag". Ele informa a última tag antes ou no commit verificado. Então isso está incorreto.

— precisa saber é

Funciona no Windows também :)

— cowlinator 20/02

49

Mostrar todas as tags no HEAD atual (ou confirmar)

git tag --points-at HEAD

— George Pavelka
fonte

1

Observe que este comando não relata um erro na linha de comando, mesmo que o resultado fique vazio. Erro? Também retorna uma lista se houver várias tags nesse local. É a melhor resposta, mas os roteiristas devem proceder com cautela, mantendo essas advertências em mente.

— ingyhere

Seguindo o comentário de @ ingyhere. Sim, é uma boa informação que não haja um erro e as pessoas precisem lidar com o resultado adequadamente. Mas eu não chamaria isso de bug. Para o meu caso, "vazio se não houver tags" é válido. Outros casos, alguém pode salvá-lo a uma variável, em seguida, verificar se ele está vazio (link para instruções bash)

— driftcatcher

23

git describeé um comando de porcelana , que você deve evitar:

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

Em vez disso, usei:

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

— Greg
fonte

11

Está retornando "indefinido"

— Stranger

4

Isso gera um rastreio ^0para confirmações que correspondem a tags (por exemplo, para tags que 1.0ele gera 1.0^0). Existe alguma maneira de ter apenas saída Git 1.0, ou devo usar o sed para isso?

— Daniel Serodio

13

Apenas algumas dicas conceituais: acho que você inverteu os significados de porcelana e encanamento. Não há problema em usar porcelana, é de alto nível e destina-se ao uso normal . O encanamento é interno (como o nome sugere) e não é recomendado apenas porque os desenvolvedores do git se reservam o direito de alterar seus argumentos e resultados sem aviso prévio. Portanto, sua primeira sugestão é realmente a mais apropriada.

— Leo Antunes

5

O artigo vinculado diz para evitar o uso de "ramificação git" porque não funciona neste caso de uso. Não consigo pensar em nenhuma boa razão para evitar o uso do git description. Como Leo diz, os comandos "Porcelain" são os comandos que você geralmente deve usar. Evite os comandos de encanamento, a menos que você realmente saiba o que está fazendo. O "git descrevem" funciona muito bem.

— Danny

4

Os comandos "Porcelain" são os que você deve usar, e não os que deve evitar. Eles são os comandos cuja saída é legível por máquina e não será alterada em versões futuras, portanto, pode-se confiar em scripts etc. legível, não porque algo importante tenha realmente mudado.

— Rjmunro

22

Quando você faz check-out de uma tag, você tem o que chamamos de "cabeça desanexada" . Normalmente, a confirmação HEAD do Git é um ponteiro para o ramo que você fez check-out no momento. No entanto, se você verificar algo diferente de uma filial local (uma tag ou uma filial remota, por exemplo), terá uma "cabeça desanexada" - você não está realmente em nenhuma filial. Você não deve fazer nenhum commit enquanto estiver em uma cabeça desanexada.

Não há problema em verificar uma tag se você não quiser fazer edições. Se você está apenas examinando o conteúdo dos arquivos ou deseja criar seu projeto a partir de uma tag, não há problema em git checkout my_tagtrabalhar com os arquivos, desde que você não faça nenhum commit . Se você deseja iniciar a modificação de arquivos, crie uma ramificação com base na tag:

$ git checkout -b my_tag_branch my_tag

criará um novo ramo chamado my_tag_branchcomeçando em my_tag. É seguro confirmar alterações neste ramo.

— mipadi
fonte

1

Resposta fantástica.

— Panos Filianos 19/01

9

git log --decorate

Isso informará o que os árbitros estão apontando para o commit do check-out atualmente.

— chriswatrous
fonte