7 padrões de commits Git que melhoram seu histórico

Mensagens de commit bagunçadas viram um passivo técnico. Quando cada desenvolvedor escreve do seu jeito, o histórico vira um amontoado de "corrige bug", "atualiza" e "commit final". Isso dificulta revisões, quebra a automação de changelogs e atrapalha a identificação de mudanças críticas.

Os padrões de commits Git resolvem isso ao estabelecer uma estrutura consistente para as mensagens. O mais conhecido é o Conventional Commits, uma convenção simples que padroniza o formato tipo(escopo): descrição. Mas existem variações e complementos que podem se encaixar melhor em cada projeto. A seguir, os 7 padrões mais relevantes, ordenados do mais impactante ao mais específico.

1. Conventional Commits

O Conventional Commits é o padrão mais adotado atualmente. Ele define uma estrutura fixa: um tipo (feat, fix, chore, docs, style, refactor, perf, test, ci, build) seguido de escopo opcional entre parênteses, dois-pontos e uma descrição curta. Exemplo: feat(auth): adiciona validação de token JWT. O grande ganho está na automação: ferramentas como semantic-release geram changelog e bump de versão automaticamente com base nesse formato. A especificação oficial, mantida no conventionalcommits.org, recomenda que mensagens com BREAKING CHANGE no corpo ou com ! após o tipo/escopo indiquem mudanças que quebram compatibilidade.

2. Angular Commit Convention

A equipe do Angular criou uma das primeiras convenções estruturadas, que serviu de base para o Conventional Commits. Ela exige um cabeçalho com tipo, escopo e descrição, seguido de corpo e rodapé opcionais. Os tipos são mais restritos: feat, fix, docs, style, refactor, perf, test, build, ci, chore. A diferença prática está na exigência de escopo e na recomendação de corpo detalhado para mudanças não triviais. Projetos que seguem Angular costumam adotar essa convenção por alinhamento com o ecossistema.

3. Padrão de Commits Semânticos (iuricode)

O repositório "iuricode/padroes-de-commits" popularizou uma versão simplificada e visual do Conventional Commits em português. Ele adiciona emojis antes do tipo para dar contexto visual rápido: :sparkles: feat: adiciona função de busca. Embora não seja um padrão formal, ganhou tração em projetos brasileiros por ser didático. O risco é que emojis não são padronizados entre sistemas operacionais e podem poluir o log se usados em excesso. Funciona bem para times pequenos que priorizam legibilidade imediata.

4. Padrão Gitmoji

Gitmoji leva o uso de emojis ao extremo: cada tipo de commit tem um emoji correspondente, como :bug: para correção de bugs e :rocket: para deploy. Existe um guia oficial em gitmoji.dev com mais de 60 emojis mapeados. A vantagem é a identificação visual instantânea no histórico. A desvantagem é a curva de aprendizado para memorizar a correspondência entre emoji e tipo. Em projetos grandes, a falta de padronização entre desenvolvedores pode gerar inconsistência.

5. Conventional Commits com escopo obrigatório

Algumas equipes adaptam o Conventional Commits para exigir escopo em todos os commits. O formato vira tipo(escopo): descrição, sem exceção. Isso é útil em monorepos ou projetos com múltiplos módulos, onde o escopo identifica claramente a área afetada. Exemplo: feat(carrinho): adiciona cálculo de frete. A rigidez adicional organiza o histórico, mas pode ser excessiva em projetos pequenos com poucos contextos.

6. Padrão de commits por categoria de mudança

Em vez de seguir uma convenção externa, algumas equipes criam sua própria taxonomia de tipos baseada na natureza da mudança: funcionalidade nova, correção, melhoria, refatoração, documentação, infraestrutura. A vantagem é o ajuste fino ao domínio do projeto. O risco é a falta de compatibilidade com ferramentas de automação que esperam tipos padronizados. Funciona bem quando o time tem disciplina para manter a taxonomia viva e documentada.

7. Padrão de commits com referência a issues

Não é um padrão de mensagem em si, mas uma prática complementar: incluir o identificador da issue ou tarefa no corpo ou rodapé do commit. Exemplo: feat: adiciona filtro por data. Corpo: Refs #342. Isso vincula o commit ao sistema de tickets, facilitando rastreabilidade. Ferramentas como GitHub e GitLab linkam automaticamente o commit à issue. É recomendado combinar com um dos padrões anteriores para não perder a estrutura semântica.

Qual padrão escolher?

Para projetos novos ou com time pequeno, o Conventional Commits puro é o ponto de partida mais seguro. Ele é suportado por ferramentas, tem documentação clara e não exige escopo obrigatório. Se o projeto usa Angular ou já segue a convenção dela, mantenha-a. Times que priorizam legibilidade visual podem testar Gitmoji ou a versão com emojis do iuricode, desde que combinem o mapeamento dos emojis em um guia interno. Monorepos se beneficiam do escopo obrigatório. E todo projeto ganha ao referenciar issues nos commits.

O importante é que o padrão seja adotado por todo o time, documentado em um CONTRIBUTING.md e verificado por ferramentas como commitlint no hook de commit. Sem consistência, nenhum padrão funciona.

Perguntas Frequentes

O que é Conventional Commits?

É uma convenção para formatar mensagens de commit com tipo, escopo opcional e descrição. Exemplo: feat(api): adiciona rota de login. A especificação está em conventionalcommits.org e permite automação de changelog e versionamento semântico.

Qual a diferença entre Conventional Commits e Angular Commit Convention?

O Angular Commit Convention serviu de base para o Conventional Commits, mas é mais restrito: exige escopo e tem tipos fixos. O Conventional Commits é mais flexível, permitindo escopo opcional e tipos personalizados desde que respeitem a estrutura.

Como validar mensagens de commit no Git?

Use o commitlint com um arquivo de configuração que define o padrão desejado. Instale como hook do husky para validar automaticamente antes do commit ser aceito. Exemplo: commitlint --edit $1 no hook commit-msg.

Emojis em commits são recomendados?

Depende do time. Emojis melhoram a legibilidade visual, mas não são padronizados entre sistemas e podem poluir o log. Se adotar, defina um mapeamento fixo e evite usar mais de um emoji por commit.

Como referenciar issues em commits?

Inclua o identificador da issue no corpo ou rodapé do commit, como Refs #123 ou Closes #456. GitHub e GitLab linkam automaticamente o commit à issue quando a referência está no formato correto.

Posso criar meu próprio padrão de commits?

Sim, desde que a equipe inteira concorde e documente a taxonomia. O risco é perder compatibilidade com ferramentas de automação. Se optar por um padrão próprio, mantenha a estrutura tipo: descrição para facilitar a leitura do histórico.