git tag e release no GitHub: marcar versões do projeto

feat: adiciona Refatoração</div>

Ela não cria objeto de tag separado com mensagem e tagger. Funciona para um marcador privado ou temporário, mas oferece menos contexto de lançamento.

Tag anotada registra quem marcou e por quê

git tag -a v1.1.0 -m "Release 1.1.0" b287fa57448a24cf40125b2ab36e47fecce086f9
git --no-pager show --no-patch --format=fuller v1.1.0

Tag anotada é um objeto com mensagem, identidade e data. Para versões publicadas, esse contexto costuma justificar a escolha. Assinatura criptográfica é uma camada adicional e exige gestão de chaves; não foi configurada no teste.

SemVer comunica compatibilidade, não qualidade

Em MAJOR.MINOR.PATCH, patch corrige sem quebrar contrato, minor adiciona funcionalidade compatível e major permite quebra. A regra depende de você ter um contrato público. Um site interno sem consumidores pode usar outra política, mas precisa documentá-la.

Não promova uma correção para minor só porque parece importante. A pergunta é se o consumidor precisa alterar uso. Pré-lançamentos como 1.2.0-beta.1 ajudam a testar, mas tag continua sendo apenas referência; pipeline e release dão o restante do processo.

Push de branch não leva todas as tags

O primeiro push publicou a branch e deixou as tags locais:

git push -u release feat/catalogo
git ls-remote --tags release

O segundo comando não escreveu nenhuma referência de tag, porque o push da branch não havia enviado tags.

Essa separação evita publicar marcadores locais por acidente. --follow-tags envia tags anotadas alcançáveis pelos commits transferidos:

git push release --follow-tags

A leve v1.0.0 permaneceu local. --tags enviou todas:

git push release --tags
git ls-remote --tags release

A linha com ^{} resolve a tag anotada para o commit. A outra aponta para o objeto da tag.

Corrija uma tag publicada com coordenação

Tag é estável por convenção, mas o Git permite apagar e recriar. Isso não atualiza automaticamente clones de outras pessoas: elas podem continuar com o objeto antigo e até reenviá-lo. Por isso, uma versão publicada errada exige aviso, decisão de compatibilidade e instrução explícita para consumidores.

No sandbox, uma tag de teste foi enviada e removida das duas pontas:

git push release v1.1.1
git tag -d v1.1.1
git push release --delete v1.1.1

Esse procedimento demonstra a mecânica, não recomenda reutilizar números. Se uma versão foi consumida, normalmente é mais claro publicar v1.1.2 com a correção e explicar v1.1.1 nas notas. Assim caches, automações e pessoas não recebem conteúdos diferentes sob o mesmo nome.

Antes de remover, use git show para confirmar o alvo e git ls-remote --tags para verificar a referência no servidor. Depois, confira a política de releases da equipe. Uma tag pode disparar deploy, pacote ou assinatura; apagar o nome não desfaz necessariamente esses efeitos externos.

Changelog nasce do intervalo real

Liste commits depois de uma versão e até outra:

git --no-pager log v1.0.0..v1.1.0 --oneline

Esse resultado é matéria-prima, não nota pronta. Traduza commits técnicos em mudanças relevantes para quem usa, destaque migrações e inclua instruções de compatibilidade. Conventional Commits ajuda a classificar, mas não entende o impacto sozinho.

Release do GitHub exige uma decisão humana

Na interface, selecione uma tag publicada, dê título e escreva notas. Você pode anexar artefatos produzidos pelo pipeline. Este material não possui autorização para criar release, então limita a prova ao objeto Git e referencia a documentação oficial para a tela.

Ao entrar numa tag para investigar, HEAD fica detached. Crie branch se for corrigir; não mova a tag publicada silenciosamente. Para apagar, remova local e remota com coordenação, sabendo que clones podem manter a referência antiga.

Antes de marcar, exija working tree limpa, testes aprovados e commit integrado na branch de entrega. Uma tag criada na branch errada continua tecnicamente válida e operacionalmente falsa. Confira git status, git branch --show-current e git show --no-patch HEAD; depois compare a tag recém-criada ao mesmo hash. Se o projeto produz artefatos, gere-os a partir do commit marcado, não de arquivos locais que ficaram fora do histórico.

Registre também quem pode publicar versões e como uma correção urgente avança o número. Esse acordo evita duas tags competindo pelo mesmo lançamento e deixa o changelog alinhado ao que realmente chegou ao consumidor.

Sua missão é criar uma tag leve e outra anotada, comparar git show, enviar com --follow-tags e conferir o que ficou de fora. Termine com um changelog entre as duas e conecte a entrega ao README, ao rebase e ao fluxo de equipe.