1. O Que E Conventional Commits

Conventional Commits e uma especificacao para padronizar mensagens de commit no Git, criada para tornar o historico de um repositorio legivel por humanos e parseavel por ferramentas automatizadas. Ao seguir o padrao, e possivel gerar changelogs, determinar bump de versao semantica e acionar pipelines de CI/CD de forma automatica.

O padrao foi criado inspirado na convencao de commits do AngularJS e hoje e adotado por projetos como Vue.js, Electron, Node.js e centenas de bibliotecas open source populares.

2. Formato e Estrutura

A estrutura completa de um commit convencional e:

tipo[escopo opcional]!: descricao

[body opcional]

[footer(s) opcionais]

• tipo: define a natureza da mudanca (feat, fix, docs, etc.)
• escopo: contexto da mudanca entre parenteses — ex: (api), (auth), (ui)
• !: exclamacao antes dos dois pontos indica breaking change
• descricao: resumo imperativo, presente, sem ponto final, max 72 chars
• body: detalhes adicionais separados por linha em branco
• footer: referencias a issues, co-autores, ou BREAKING CHANGE

3. Os 11 Tipos e Quando Usar Cada Um

A especificacao define apenas feat e fix como obrigatorios, mas a comunidade adotou 11 tipos padrao:

• feat: nova funcionalidade visivel para o usuario final
• fix: correcao de bug visivel para o usuario
• docs: mudancas apenas em documentacao
• style: formatacao, ponto-e-virgula, espacamento — sem mudanca de logica
• refactor: reestruturacao de codigo sem nova feature ou correcao de bug
• test: adicao ou correcao de testes
• perf: mudanca que melhora performance
• build: mudancas no sistema de build ou dependencias externas
• ci: mudancas em configuracoes de CI/CD
• chore: manutencao que nao se encaixa em outros tipos
• revert: reverter um commit anterior

4. Relacao com SemVer

Conventional Commits mapeia diretamente para o versionamento semantico:

• feat → bump MINOR (1.2.0 → 1.3.0)
• fix, perf, revert → bump PATCH (1.2.0 → 1.2.1)
• BREAKING CHANGE (qualquer tipo com !) → bump MAJOR (1.2.0 → 2.0.0)
• Outros tipos → sem bump de versao

5. Ferramentas que Usam o Padrao

O ecossistema em torno de Conventional Commits e robusto:

• semantic-release: automatiza release, changelog e publicacao no npm
• commitlint: valida mensagens de commit em hooks do git
• standard-version: bump de versao e changelog automaticos
• conventional-changelog: gera CHANGELOG.md a partir do historico
• husky: gerencia git hooks para rodar commitlint antes do commit

6. Perguntas Frequentes

Devo usar emojis nos commits?

E opcional. Alguns projetos usam emojis como prefixo visual (ex: gitmoji), mas a especificacao Conventional Commits nao exige nem proibe. O mais importante e a consistencia dentro do projeto.

Posso ter multiplos tipos num commit?

Nao. Cada commit deve ter apenas um tipo. Se voce fez uma correcao de bug e adicionou uma feature ao mesmo tempo, o recomendado e dividir em dois commits separados para manter o historico granular e o versionamento preciso.

O padrao funciona com branches de feature?

Sim. Conventional Commits funciona independente da estrategia de branching. Em projetos com squash merge, apenas o commit do merge precisa seguir o padrao. Em projetos sem squash, todos os commits devem seguir.