Neste artigo, darei dicas de como trabalhar com tags no Git.

?

Rótulos descritivos

O Git fornece alguns mecanismos para identificar as mudanças por rótulos em vez de valores únicos de hash.

O primeiro deles, do qual já falei aqui, são branches. Quando mudamos de um branch para outro, estamos na verdade utilizando o rótulo descritivo para identificar o commit específico para qual mudar. O segundo, que introduziremos neste artigo, são as tags. Uma tag é como um branch, uma vez que ela identifica um commit específico com um rótulo descritivo.

Branches versus tags

Qual a diferença entre tags e branches? A área de trabalho é (quase sempre) associada com um branch, chamado master por padrão. Quando isso acontece, o commit irá automaticamente atualizar a referência master para apontar para o novo commit; em outras palavras, branches são referências mutáveis.

Uma tag, por outro lado, é criada para apontar para um commit específico e, portanto, não muda, mesmo se a branch seguir em frente. Em outras palavras, tags são referências imutáveis.

Annotated tags

O Git tem dois tipos de tags: annotated e non-annotated. Ao usá-las, existe uma pequena diferença entre elas. Ambas permitem que você faça referência a um commit específico em um repositório.

Uma annotated tag cria uma objeto tag adicional no repositório do Git, o que permite que você armazene informações associadas com a tag. Isso pode incluir notas de liberação, a meta-informação sobre o lançamento e, opcionalmente, uma assinatura para verificar a autenticidade do commit para o qual ele aponta.

Exemplos

Podemos criar uma tag simples, baseada na versão atual do repositório, com: 

$ git tag example

Isso cria uma lightweight tag como referência no .git/refs/tags/example, que aponta para o commit atual. Se quisermos deixá-la como uma annotated tag, precisamos fornecer -a, e uma mensagem com -m:

$ git tag -a v1 -m "Version 1 release"

Isso criará um objeto annotated tag (não assinado), contendo a mensagem e um apontador para o objeto commit. Agora, a referência em .git/refs/tags/v1 apontará para a tag do objeto, que então apontará para o commit.

Se quisermos garantir a autenticidade da tag, poderíamos usar -s no comando da tag do commit. Ele usa o gpg para assinar, baseado no seu endereço de e-mail – apesar de que você pode usar -u para especificar uma diferente identidade de gpg. Você pode verificar a assinatura de uma tag existente com -v.

Para listar as tags do repositório local, execute git tag sem nenhum argumento; ou, para um padrão, use -l with * como um coringa:

$ git tag
example
v1
v1s
$ git tag -l *s
v1s

Finalmente, para se livrar das tags, você pode deletá-las com -d:

$ git tag -d v1
$ git tag
example
v1s

Deletar tags é ok se você nunca as tiver disponibilizado publicamente, mas você realmente deveria evitar deletar tags desde que você tenha colocado em um local publicamente legível. Similarmente, você não deveria mudar a tag, uma vez que ela tenha sido lançada.

Conteúdos e descrições

Com o objetivo de ver o que a tag contém, você pode usar git show, da mesma maneira que você pode usar outros objetos git:

$ git show v1s
tag v1s
Tagger: Al Blue <alblue@example.com>
Date:   Tue Apr 20 09:00:00 2011 +0100

Version 1 signed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iF4EABEITke4AkyRUh8ACgkQWwXM3hQMKHZq5QD/esqKyinelXGM1TSzUqEzuBdI
Ah2Cq/5TS3j4kiP4+UUA/2nN2SVoWwYryN9234kgWUvZIrV1P0FGTG+lAEN5avj3
=JICf
-----END PGP SIGNATURE-----

commit 91a2b24....

Se a tag é uma annotated tag, você verá a mensagem e a tag do objeto, seguidos pelo commit. Se a tag é uma lightweight tag, então você verá somente o objeto commit.

A principal diferença entre annotated e non-annotated tags é o uso do git describe. Isso gera um identificador do repositório, baseado na annotated tag mais próxima. Se fôssemos executar agora, veríamos uma referência à annotated tag v1s.

$ git describe
v1s

Se o commit atual combina perfeitamente com o de uma tag, então somente o nome da tag é impresso. Se existirem mudanças, o git describe irá imprimir o nome da tag, um hífen, o número de commits feitos, um hífen, a letra ‘g’ e então o identificador do commit. Isso permite que qualquer um use uma revisão explícita para identificar o commit, através do hash no final. Assim, ele é muitas vezes usado para incluí-lo nas versões do arquivo como meios de identificá-lo em um estágio avançado. 

# Add a commit
$ touch file
$ git add file
$ git commit -m "Adding file"
$ git describe
v1s-1-g24242c3

A letra g é adicionada para denotar uma versão gerenciada do git; portanto outros repositórios podem usar o mesmo formato, substituindo aquela letra por uma diferente.

Se nenhuma annotated tag for encontrada, então ele irá imprimir fatal: No names found, cannot describe anything. Para permitir que o describe utilize non-annotated tags, execute git describe –tags. Também é possível fazer com que ele descreva contra um branch, usando git describe –all, apesar de que isso só faz sentido se a branch é conhecida remotamente.

Pushing e pulling

Como uma tag (annotated ou lightweight) é apenas uma referência no seu repositório local, ela não é enviada por padrão para o repositório remoto durante pushes. (Essa é uma diferença notável entre Git e Hg). Em vez disso, você pode usar git push na tag individualmente, ou você pode executar git push –tags, o que irá aplicar push em todas as tags. Para tags “livres”, (p.e. V1.0.0) é convencionado que elas sejam annotated tags; é relativamente raro você utilizar o push em uma lightweight tag para um repositório local.

Para o pulling, quaisquer tags associadas com sua branch atual serão buscadas quando você der uma olhada nelas. Isso pode resultar em não ter, em seu repositório local, todas as tags contidas no repositório remoto. Se você quiser buscar por todas elas, você pode fazer git fetch –tags para puxar todas para dentro, ou git fetch tag para puxar somente uma.

?

Texto original disponível em http://alblue.bandlem.com/2011/04/git-tip-of-week-tags.html