Tipos de apoio: chore, docs, refactor e os outros

feat e fix são os únicos que mudam a versão por padrão. O resto do tempo você está mexendo em coisas que não alteram o comportamento pra quem usa: organizar código, escrever doc, ajustar build. Esses são os tipos de apoio.

os mais comuns

• chore - tarefa de manutenção que não mexe em código de produto: atualizar dependência, ajustar CI, renomear arquivo de config.

  copiar

  chore(deps): atualiza typescript de 5.4 para 5.6
  

• docs - muda só em documentação.

  copiar

  docs(readme): explica como rodar o projeto localmente
  

• refactor - reescreve código sem mudar comportamento. É a grande diferença: se quebrou ou acrescentou comportamento, não é refactor.

  copiar

  refactor(auth): extrai validação de senha para função própria
  

• test - mexe em testes (novos, corrigidos, reestruturados), sem tocar no código de produção.

  copiar

  test(cart): cobre cálculo de frete com frete grátis e pago
  

• style - formatação/aparência do código: espaçamento, ponto e vírgula, lint que não muda lógica. Não confundir com CSS de produto: mudança visual na interface do usuário é feat (componente novo) ou fix (visual quebrado).

  copiar

  style: aplica prettier no diretório src
  

• build - mudanças no sistema de build ou dependências externas (npm, webpack, dockerfile): diferente de chore por focar em build/empacotar.

  copiar

  build(docker): ajusta multi-stage build para reduzir imagem
  

• ci - apenas configuração de integração contínua (GitHub Actions, scripts de pipeline), sem tocar em código de produção.

• perf - melhora performance sem mudar o comportamento visível. Em geral não dispara bump por padrão (só feat/fix/BREAKING CHANGE mexem na versão na maioria das ferramentas). Se a otimização muda contrato público, é feat! ou BREAKING CHANGE; se é interna, perf puro.

perf(lista): memoiza renderização de itens

• revert - desfaz um commit anterior. Tem uma sintaxe específica: o body descreve qual SHA está sendo revertido, pra manter rastreabilidade.

revert: feat(auth): adiciona login com Google

Reverts abc1234

Dica: a comunidade usa mais tipos do que a especificação cita (ex.: feat, fix, refactor, test) e cada time costuma fechar a própria lista ali. O importante é ter poucos tipos, bem definidos - não 15 - pra que ler o histórico continue sendo rápido.

Tirando a ambiguidade: chore vs build vs ci

A linha entre esses três é fina e confunde. Regra prática:

Quando o time é pequeno e o vocabulário único não importa muito, alguns colapsam tudo em chore e pronto. O importante é o time fechar a escolha e o commitlint refletir.

Como escolher entre os parecidos

O atalho do estilo type: muda o que pra quem:

• mexeu no comportamento do usuário? → feat (novo) ou fix (errado).

• mexeu na forma, mantendo o comportamento? → refactor.

• mexeu em doc/test/CI/build? → docs / test / ci / build.

• não encaixou em nenhum / manutenção genérica? → chore.

• tipos de apoio = chore, docs, refactor, test, style, build, ci, perf.

• regra = nenhum deles muda a versão por padrão (só feat/fix/BREAKING).

• coesão = poucos tipos, bem definidos; evite tipos inventados demais.

Dica: se o time ainda não fechou a lista de tipos, comece com um subconjunto pequeno e cresça sob demanda. feat, fix, refactor, docs, test, chore já cobrem ~90% dos commits.

No próximo nó, vamos ver escopo e assunto - o que colocar (ou não) na primeira linha.