Por que mensagens de commit importam

Todo mundo já fez aquilo: um dia de trabalho, um "commit" e a mensagem fix stuff (ou wip, ou simplesmente asd). Funciona na hora, o trabalho está salvo, e o problema fica pra depois. Só que depois chega - três meses, dez commits e um git log que não conta nada.

Antes de decorar o formato, vamos entender o problema que o Conventional Commits resolve. Porque ele não existe por estética.

O histórico é um local de trabalho

Quando você abre o histórico do projeto, o que quer descobrir? Na maioria das vezes, isso:

• o que mudou nesse release (pra preencher o changelog)
• qual commit quebrou alguma coisa (pra achar o culpado)
• em que PR essa feature entrou (pra entender a decisão)

Olha o que dá pra descobrir com o git log quando a mensagem conta uma história:

# só o que entrou na última release, organizado
git log v1.2.0..v1.3.0 --oneline

Com commits feat: x e fix: y, essa lista é clara. Com wip, fix stuff e asd, é um monte de texto que não diz nada - você vai acabar abrindo commit por commit pra entender.

Dica: a mensagem de commit é a única coisa sobre o seu trabalho que atinge outra pessoa sem ela te perguntar. Código você revisa; a mensagem é o primeiro contato automático do time com a mudança.

O que o Conventional Commits é (e o que não é)

A especificação é curta, mas ela apoia três coisas ao mesmo tempo:

• Comunicar ao time o que cada mudança faz - num formato que humanos e ferramentas leem igual.
• Automatizar versão e changelog: ferramentas inferem o bump de Semantic Versioning a partir de feat e fix.
• Filtrar o histórico com facilidade (git log --grep="^feat").

Não é sobre escrever inglês bonito nem sobre engessar a criatividade. É um contrato mínimo - o suficiente pra uma pessoa (ou um bot) extrair significado sem adivinhar.

• Mensagem de commit => comunicação entre pessoas (e o seu "eu" do futuro).
• Convenção de formato => consistência que a ferramenta consegue ler.
• SemVer => regra que liga o formato à versão do software.

Dica: no próximo nó, vamos ver o formato exato type(escopo): descrição. Por ora, o importante é o porquê: commit convencional vira dado, não ruído.

No próximo nó, vamos montar a estrutura de uma mensagem convencional.

Quando NÃO vale a pena: num projeto solo de fim de semana, num protótipo descartável ou num time de 2 devs que faz um deploy por mês, a convenção inteira é overhead. Ela paga quando vira contrato compartilhado entre humanos, ferramentas e consumidores - é o caso típico de time com release frequente ou biblioteca pública.