Tags, releases e versionamento semântico
Um commit marca 'o que mudou'; uma tag marca 'isso aqui foi uma versão publicada' — e o número da versão devia contar uma história.
git log mostra dezenas de commits, mas nem todos representam algo publicado. Uma tag marca um commit específico como "isso aqui é a versão 2.1.0" — um ponto fixo no histórico que não se move, diferente de uma branch (que avança a cada commit novo).
Tag leve vs. tag anotada
git tag v2.1.0 # tag leve — só um ponteiro pro commit, sem metadado
git tag -a v2.1.0 -m "Release 2.1.0" # tag anotada — guarda autor, data e mensagem, como um commitTag leve é um apelido rápido pra um commit, sem mais informação. Tag anotada é um objeto completo no git — guarda quem criou, quando, e uma mensagem — e por isso é a recomendada pra marcar releases de verdade: se alguém perguntar "quem gerou a v2.1.0 e por quê", a resposta está na própria tag.
git show v2.1.0git push origin v2.1.0 # manda uma tag específica
git push origin --tags # manda todas as tags locais que ainda não estão no remotoVersionamento semântico (semver): major.minor.patch
Semver é uma convenção pra que o número da versão sozinho já diga o tamanho e o risco da mudança, sem precisar ler o changelog inteiro: MAJOR.MINOR.PATCH, por exemplo 2.1.3.
MAJOR (2.x.x) → mudança incompatível — quebra quem usa a versão anterior (breaking change)
MINOR (x.1.x) → funcionalidade nova, mas compatível com o que já existia
PATCH (x.x.3) → correção de bug, sem adicionar funcionalidade nem quebrar nadaIsso importa na prática: uma biblioteca que vai de 2.4.0 pra 2.5.0 deveria ser segura de atualizar sem revisar código; de 2.4.0 pra 3.0.0 exige atenção, porque algo que funcionava pode ter mudado de comportamento ou sido removido.
Tags e releases no GitHub
No GitHub, uma "Release" normalmente é criada a partir de uma tag — a tag marca o commit exato no git; a release adiciona uma camada em cima (notas da versão, binários anexados, changelog gerado automaticamente a partir dos PRs mergeados desde a tag anterior). A tag é o dado que o git entende; a release é a vitrine legível pra quem só quer saber "o que mudou nessa versão".
Exercício
Uma biblioteca está na versão 1.8.2. Você corrigiu um bug sem adicionar nada novo nem quebrar compatibilidade. Qual deveria ser a próxima versão, seguindo semver, e qual comando cria a tag anotada correspondente?