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

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

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:

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.

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

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:

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.

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:

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:

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:

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:

Podes ver que marcaste o commit:

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>.

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á.

Agora, quando alguém clona ou puxa do teu repositório, eles também receberão todas as tuas 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:

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:

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.