Conventional Commits

Definition

Conventional Commits é a convenção de mensagens de commit em que cada commit declara um tipo e um escopo em formato estruturado (feat:, fix:, chore:, etc.), opcionalmente com BREAKING CHANGE. Essa disciplina transforma a mensagem de commit em metadado legível por máquina que dirige o versionamento semântico e a geração automática de changelog. O ecossistema conventional-changelog é a implementação de referência: ferramentas e bibliotecas que leem as mensagens de commit e geram CHANGELOG e release notes a partir delas.

Para o founder/PM não-técnico, o ponto é simples: se toda mudança entra com uma mensagem de commit padronizada, o “histórico do que fizemos” e o “qual a próxima versão” deixam de ser trabalho manual e passam a cair automaticamente do fluxo de trabalho.

Key Points

  • Commit → release, sem etapa manual. A ferramenta gera CHANGELOG a partir de git metadata; a disciplina na mensagem (feat = versão menor, fix = patch, BREAKING CHANGE = major) é o que determina o bump de versão. O “Complete Guide” da spec é a porta de entrada recomendada pelo próprio repo.

  • Cada etapa do release tem um módulo dedicado. conventional-recommended-bump sugere o bump de versão a partir dos commits; commitlint linta as mensagens (recusa commits fora do padrão); commitizen dá convenção interativa; standard-changelog aplica o formato Angular. Juntos eles automatizam o ciclo bump → changelog → release.

  • Ferramentas de nível alto resolvem o release inteiro. O repo recomenda três opções acima dos módulos individuais: semantic-release (automatiza versionamento + changelog + publish no CI/CD), commit-and-tag-version (drop-in do npm version), e simple-release-action (GitHub Action para versionamento/changelog, com suporte a monorepos).

  • A convenção virou uma skill de agente. O repo publica a skill conventional-commit-message (“helps write Conventional Commit messages”), instalável via pnpx skills add conventional-changelog/conventional-changelog --skill conventional-commit-message (ou npx). É o mesmo movimento de agent-rules-books: uma convenção de engenharia destilada em instrução executável para o agente escrever commits corretos no primeiro passe.

  • Maturidade: ISC license, 8.5k stars; suporta apenas versões LTS do Node — remover um LTS antigo é tratado como breaking change (nova major), um sinal de disciplina de versionamento aplicada ao próprio projeto.

Implications

Para quem constrói produto com IA, Conventional Commits é a etapa que fecha o ciclo de entrega: ele conecta o commit (fim de ciclo-issue-branch-pr-merge) ao release automático. É complementar a repository-quality-standards: aquela governa o que dentro do repo deve estar limpo (lint, hygiene, review); esta governa como a mensagem de commit vira histórico e versão utilizáveis. E a emergência de uma skill de agente para escrever a mensagem mostra o mesmo padrão que agent-rules-books detectou — convenções verbais estão virando regras carregáveis, porque pedir “escreva boas mensagens de commit” funciona pior do que dar a spec como instrução.

Um founder pode adotar só a periferia (a skill + commitlint para rejeitar commit fora do formato) sem subir um pipeline inteiro de semantic-release — o ganho mínimo já é um histórico de mudanças legível e versionamento honesto.

Open Questions

  • Este snapshot cobre a ferramenta/ecossistema (conventional-changelog/conventional-changelog), não a especificação Conventional Commits em si (que vive em conventionalcommits.org); a spec é referenciada por link, mas o texto-tipo/escopo/BREAKING não é transposto aqui.
  • Não fica claro o custo de adoção para projeto sem tooling JS (commitlint/semantic-release são Node) — founder fora do ecossistema Node pode precisar de equivalente nativo da sua stack.

Sources