Git 🌙
Chapters ▾ 2nd Edition

2.6 Noções Básicas do Git - Tagging

Tagging

Como a maioria dos VCSs, Git tem a habilidade de marcar pontos específicos no histórico como sendo importantes. Normalmente, as pessoas usam esta funcionalidade para marcar os pontos de lançamento (v1.0 e assim por diante). Nesta seção, aprenderás como listar as tags disponíveis, como criar novas tags e quais são os diferentes tipos de tags.

Listar as tuas tags

Listar as tags disponíveis no Git é direto. Basta digitar git tag (com opcional -l ou --list):

$ git tag
v0.1
v1.3

Este comando lista as tags em ordem alfabética; A ordem em que aparecem não tem importância real.

Tu podes procurar por tags que correspondam a um padrão específico. O repositório fonte Git, por exemplo, contém mais de 500 tags. Se tu só estiveres interessado em olhar para a série 1.8.5, podes executar isto:

$ git tag -l "v1.8.5*"
v1.8.5
v1.8.5-rc0
v1.8.5-rc1
v1.8.5-rc2
v1.8.5-rc3
v1.8.5.1
v1.8.5.2
v1.8.5.3
v1.8.5.4
v1.8.5.5
Example 2. Listar tag wildcards requer a opção -l ou --list

Se tu quiseres apenas a lista completa de tags, executar o comando git tag implica implicitamente que tu pretendes uma lista e fornece uma; O uso de -l ou --list neste caso é opcional.

Se, no entanto, estiveres a fornecer um padrão de wildcard para coincidir com os nomes das tags, o uso de -l ou --list é obrigatório.

Criar Tags

O Git suporta dois tipos de tags: lightweight e annoteted.

Uma tag leve é muito parecida com um ramo que não muda — é apenas um ponteiro para um commit específico.

As tags anotadas, no entanto, são armazenadas como objetos completos na base de dados Git. Elas são assinaladas; conter o nome do tagger, o email e a data; ter uma mensagem de tagging; e pode ser assinado e verificado com o GNU Privacy Guard (GPG). Geralmente, é recomendável que cries tags anotadas para que possas ter toda esta informação; mas se tu quiseres uma tag temporária ou, por algum motivo, não quiseres manter as outras informações, as tags leves também estão disponíveis.

Tags Anotadas

Criar uma tag anotada no Git é simples. A maneira mais fácil é especificar -a quando executas o comando tag:

$ git tag -a v1.4 -m "minha versão 1.4"
$ git tag
v0.1
v1.3
v1.4

O -m especifica uma mensagem de tagging, que é armazenada com a tag. Se não especificares uma mensagem para uma tag anotada, o Git lança o teu editor para que possas digitá-lo.

Podes ver os dados da tag juntamente com o commit que foi tagget usando o comando git show:

$ git show v1.4
tag v1.4
Tagger: Ben Straub <ben@straub.cc>
Data:   Sab Mai 3 20:19:12 2014 -0700

a minha versão  1.4

commit ca82a6dff817ec66f44342007202690a93763949
Autor: Scott Chacon <schacon@gee-mail.com>
Data:   Seg Mar 17 21:52:11 2008 -0700

    alterou o número da versão

Isto mostra a informação do tagger, a data em que o commit foi tagget e a mensagem de anotação antes de mostrar as informações de confirmação.

Tags Leves

Outra maneira de marcar compromissos é com uma tag leve. Esta é basicamente a soma da verificação do compromisso armazenada num arquivo — nenhuma outra informação é mantida. Para criar uma tag leve, não forneçe nenhuma das opções -a, -s ou -m, basta fornecer um nome de tag:

$ git tag v1.4-lw
$ git tag
v0.1
v1.3
v1.4
v1.4-lw
v1.5

Desta vez, se tu executares o git show na tag, não verás as informações adicionais da tag. O comando mostra apenas o commit:

$ git show v1.4-lw
commit ca82a6dff817ec66f44342007202690a93763949
Autor: Scott Chacon <schacon@gee-mail.com>
Data:   Seg Mar 17 21:52:11 2008 -0700

    alterou o número da versão

Tagging Mais Tarde

Também podes marcar compromissos depois de passares por eles. Supões que o teu histórico de confirmação se pareça com isto:

$ git log --pretty=oneline
15027957951b64cf874c3557a0f3547bd83b3ff6 Merge branch 'experiência'
a6b4c97498bd301d84096da251c98a07c7723e65 início do suporte de escrita
0d52aaab4479697da7686c15f77a3d64d9165190 mais uma coisa
6d52a271eda8725415634dd79daabbc4d9b6008e Merge branch 'experiência'
0b7434d86859cc7b8c3d5e1dddfed66ff742fcbc adicionou uma função de commit
4682c3261057305bdd616e23b64b0857d832627b adicionou um arquivo todo
166ae0c4d3f420721acbb115cc33848dfcc2121a começou a gravar suporte
9fceb02d0ae598e95dc970b74767f19372d61af8 arquivo de rake atualizado
964f16d36dfccde844893cac5b347e7b3d44abbc commit o todo
8a5cbc430f1a9c3d00faaeffd07798508422908a leia-me atualizado

Agora, supõe que te tenhas esquecido de marcar o projeto na v1.2, que estava no commit de "ficheiro rake atualizado". Tu podes adicioná-lo após o fato. Para marcar este commit, tu especificas a soma de verificação de commit (ou parte dela) no final do comando:

$ git tag -a v1.2 9fceb02

Podes ver que marcaste o commit:

$ git tag
v0.1
v1.2
v1.3
v1.4
v1.4-lw
v1.5

$ git show v1.2
tag v1.2
Tagger: Scott Chacon <schacon@gee-mail.com>
Data:   Seg Fev 9 15:32:16 2009 -0800

versão 1.2
commit 9fceb02d0ae598e95dc970b74767f19372d61af8
Autor: Magnus Chacon <mchacon@gee-mail.com>
Data:   Dom Abr 27 20:43:35 2008 -0700

    arquivo de rake atualizado
...

Partilhar Tags

Por padrão, o comando git push não transfere tags para os servidores remotos. Tu precisarás empurrar explicitamente as tags para um servidor compartilhado depois de as ter criado. Este processo é como compartilhar filiais remotos — podes executar origem git push <tagname>.

$ origem git push v1.5
Contando objetos: 14, feito.
Compressão Delta usando até 8 tópicos.
Comprimir objetos: 100% (12/12), feito.
Escrevendo objetos: 100% (14/14), 2.05 KiB | 0 bytes/s, feito.
Total 14 (delta 3), reutilizado 0 (delta 0).
Para git@github.com:schacon/simplegit.git
 * [nova tag]         v1.5 -> v1.5

Se tu tens muitas tags que desejas pressionar de uma só vez, também podes usar a opção --tags para o comando` git push`. Isto transferirá todas as tuas tags para o servidor remoto que ainda não estão lá.

$ origem git push --tags
Contando objetos: 1, feito.
Escrevendo objetos: 100% (1/1), 160 bytes | 0 bytes/s, feito.
Total 1 (delta 0), reutilizado 0 (delta 0)
Para git@github.com:schacon/simplegit.git
 * [new tag]         v1.4 -> v1.4
 * [new tag]         v1.4-lw -> v1.4-lw

Agora, quando alguém clona ou puxa do teu repositório, eles também receberão todas as tuas tags.

Verificando as Tags

Se tu quiseres veres as versões dos arquivos que uma tag está a apontar para, tu podes fazer um check-in git, embora isto coloca o teu repositório no estado “CABEÇA destacada”, que tem alguns efeitos secundários:

$ saindo do git 2.0.0
Nota: saindo '2.0.0'.

Tu estás no estado "cabeça destacada". Podes olhar ao redor, fazer experiências
muda e compromete-os, e podes descartar quaisquer compromissos que tu fizeres neste
estado sem afetar nenhum ramo executando outro checkout.

Se tu quiseres criar um novo ramo para manteres os compromissos que criaste, podes
fazer isto (agora ou mais tarde) usando -b com o comando checkout novamente. Exemplo:

  git checkout -b <novo-ramo>

CABEÇA está agora em 99ada87... Merge pull request #89 de schacon/appendix-final

$ git checkout 2.0-beta-0.1
A posição da CABEÇA tem 99ada87... Merge pull request #89 de schacon/appendix-final
CABEÇA está agora em df3f601... adiciona atlas.json e imagem de capa

No estado “CABEÇA destacada”, se fizeres alterações e, em seguida, criar um commit, a tag permanecerá igual, mas a tua nova confirmação não pertencerá a nenhum ramo e será inacessível, exceto pelo hash de commit exato. Assim, se tu precisares de fazer alterações — digamos que tu estás corrigindo um bug numa versão mais antiga, por exemplo — tu geralmente quererás criar uma filial:

$ git checkout -b versão2 v2.0.0
Mudou para um novo ramo'versão2'

Se tu fizeres isto e fazeres um commit, o teu ramo versão2 será ligeiramente diferente do teu tag v2.0.0, uma vez que avançará com as tuas novas mudanças, então tem cuidado.

scroll-to-top