# 7 padrões de commits Git que melhoram seu histórico > Os 7 padrões de commits Git (Conventional Commits, commits atômicos, mensagens imperativas, escopo claro, corpo descritivo, referência a issues e uso de emojis) organizam o histórico do repositório. Esses padrões facilitam revisões de código, automatizam a geração de changelogs e reduzem o passivo técnico de mensagens bagunçadas. *Net Propaganda · Apps e Software · 23 de julho de 2026 · Walquíria Bensaúde Tomaz* Mensagens de commit bagunçadas viram um passivo técnico. Conheça 7 padrões de commits Git que organizam o histórico, facilitam revisões e automatizam changelogs. 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. --- Fonte (canonical): https://netpropaganda.com.br/apps-e-software/7-padroes-de-commits-git-que-melhoram-seu-historico/