Uso de Tags para Controle de Versões, Eventos e Marcos do Projeto
Depois que a estratégia de branches está bem definida, o próximo elemento que dá maturidade ao repositório é o uso disciplinado de tags. Muita gente usa tag apenas para marcar versões finais, como v1.0.0 ou v2.3.1, mas a estratégia que usamos apresentada vai além disso: também usamos tags para registrar início e fim de implementações, além de eventos relevantes do projeto e até marcos ligados ao cliente. Essa é uma prática extremamente valiosa, porque transforma o Git não apenas em um controle de versão, mas também em uma espécie de trilha histórica técnica do projeto.
Em termos simples, uma tag é um marcador fixo apontando para um commit específico. Diferentemente de um branch, que continua avançando conforme novos commits são feitos, a tag permanece presa exatamente ao ponto onde foi criada. Isso a torna ideal para registrar momentos importantes da vida do software.
Há dois tipos mais comuns de tags no Git. O primeiro é a tag leve, que funciona quase como um apelido simples para um commit. O segundo é a tag anotada, que é a forma mais profissional de uso, pois armazena autor, data e mensagem associada à marcação. Em projetos sérios, especialmente quando há mais de uma pessoa envolvida ou quando o histórico precisa servir como documentação, a tag anotada é a melhor escolha.
Para criar uma tag anotada de versão, por exemplo, você pode usar:
git tag -a v1.2.0 -m "Versão 1.2.0 liberada para produção"
Nesse caso, -a indica que a tag será anotada e -m define a mensagem que descreve o marco registrado. Depois disso, para enviar a tag ao repositório remoto, é necessário publicá-la explicitamente:
git push origin v1.2.0
Se quiser enviar todas as tags locais de uma vez, pode usar:
git push origin --tags
Essa prática é importante porque muitos desenvolvedores criam tags localmente e esquecem de publicá-las, o que compromete a rastreabilidade coletiva do projeto.
Na sua estratégia, uma aplicação especialmente interessante das tags é marcar o início e o fim de uma implementação. Isso ajuda bastante quando se deseja reconstruir a linha do tempo de uma funcionalidade. Suponha que você vá iniciar a implementação de um novo módulo de comunicação Bluetooth. Você poderia marcar o ponto de partida assim:
git tag -a start-bluetooth-module -m "Início da implementação do módulo Bluetooth"
git push origin start-bluetooth-module
Mais adiante, ao concluir essa funcionalidade, pode registrar:
git tag -a end-bluetooth-module -m "Fim da implementação do módulo Bluetooth"
git push origin end-bluetooth-module
Com isso, qualquer pessoa da equipe pode comparar os dois marcos e entender com clareza quais commits compuseram aquela implementação. Inclusive, o Git permite comparar o intervalo entre duas tags com bastante facilidade:
git log start-bluetooth-module..end-bluetooth-module --oneline
Esse comando lista os commits existentes entre os dois pontos marcados. Da mesma forma, você pode ver as diferenças no conteúdo do código:
git diff start-bluetooth-module..end-bluetooth-module
Isso é extremamente útil quando se quer auditar uma entrega, revisar uma funcionalidade específica ou até preparar documentação técnica do que foi alterado em determinado ciclo.
Outro uso muito inteligente das tags, presente na sua abordagem, é registrar eventos relevantes ligados ao projeto ou ao cliente. À primeira vista isso pode parecer incomum, mas faz bastante sentido em ambientes profissionais. Imagine, por exemplo, que em determinada data foi feita uma homologação importante com o cliente, ou que um requisito crítico foi aprovado, ou ainda que uma demonstração relevante foi realizada. Em vez de deixar isso perdido apenas em e-mails, mensagens ou atas, você pode deixar um marco técnico direto no repositório:
git tag -a client-approval-2026-03-19 -m "Cliente aprovou a arquitetura da versão 2.0"
git push origin client-approval-2026-03-19
Essa prática não substitui documentação formal, mas fortalece enormemente o valor histórico do repositório. Ela cria pontos de referência que ajudam a correlacionar decisões de negócio com o estado real do código naquele momento.
Também vale destacar que tags podem ser criadas não apenas no commit atual, mas em qualquer commit específico. Para isso, basta informar o hash:
git tag -a v1.1.0 3f9a2bc -m "Versão 1.1.0 homologada"
Isso é útil quando você percebe depois que determinado commit deveria ter sido marcado como um marco importante.
Para listar as tags existentes no projeto, o comando é simples:
git tag
Se quiser filtrar por padrão, por exemplo apenas versões:
git tag -l "v*"
E, para visualizar detalhes de uma tag específica:
git show v1.2.0
Esse comando exibe a anotação da tag, o commit correspondente e o diff associado, dependendo do contexto.
Existe ainda um ponto conceitual importante aqui. Quando você usa tags de forma rica e frequente, o Git passa a servir como uma ferramenta de governança técnica. Em vez de ser apenas um local onde o código mora, ele passa a ser também um registro auditável da evolução do software. Isso é especialmente valioso em contextos com firmware, produtos embarcados, sistemas industriais e projetos onde o histórico técnico tem importância operacional ou contratual.
No entanto, para que isso funcione bem, é importante manter uma convenção de nomes coerente. Um projeto pode, por exemplo, adotar padrões como vX.Y.Z para versões, start-* e end-* para ciclos de implementação, e event-* ou client-* para marcos externos. O mais importante não é qual nome será usado, mas que exista consistência. Um repositório com tags criadas de forma aleatória perde boa parte do valor organizacional que elas poderiam oferecer.
Em resumo, as tags complementam os branches de forma brilhante. Enquanto os branches representam linhas de trabalho em evolução, as tags congelam pontos significativos da história do projeto. Na estratégia que você apresentou, isso cria uma combinação muito forte: branches organizam o fluxo de desenvolvimento, e tags transformam esse fluxo em um histórico técnico legível, rastreável e útil para a equipe e para a gestão do projeto.
Na próxima seção, vamos aprofundar o uso de Issues, commits referenciados e rastreabilidade no GitHub, mostrando como ligar branch, commit, tag e tarefa em uma mesma cadeia de acompanhamento.
