Verifique uma mensagem de commit segundo Conventional Commits e commitlint, com o salto de versão
Funciona no seu navegador. Nada do que você digita é enviado a lugar nenhum. Verificado em 16 de outubro de 2026.Um conventional commit começa com um tipo, um scope opcional e uma descrição, como "fix(api): handle empty response". Cole uma mensagem para verificá-la com as 12 regras do config-conventional do commitlint, ver as partes dela e ver a versão que ela gera: feat é minor, fix é patch e uma mudança incompatível é major.
Esta página foi traduzida automaticamente do original em inglês. Nenhuma pessoa revisou ainda a tradução; a versão em inglês é a que deve ser considerada. Ler o original em inglês
Cole a mensagem de commit ou toque em um tipo, como feat ou fix, para começar uma.
Leia o resultado: cada regra violada, em palavras simples, com as partes em que a mensagem foi interpretada.
Corrija a mensagem até ela passar; a linha de versão mostra se ela gera uma versão major, minor ou patch.
Para um pull request inteiro, mude para Uma lista de cabeçalhos e cole a saída de git log --format=%s.
Conventional Commits é um formato pequeno para mensagens de commit que as ferramentas conseguem ler: ferramentas de release escolhem a partir dele o próximo número de versão, e ferramentas de changelog o transformam em notas de versão. Muitas equipes o exigem com o commitlint em um hook commit-msg, e uma mensagem de commit rejeitada é uma pequena frustração comum.
O formato. Um cabeçalho e depois um corpo e rodapés opcionais, cada um separado por uma linha em branco:
| Parte | Exemplo | Regra |
|---|---|---|
| Tipo | feat, fix, docs |
Um de 11, em minúsculas |
| Scope | (api) |
Opcional, entre parênteses |
| Incompatível | ! antes dos dois-pontos |
Ou um rodapé BREAKING CHANGE |
| Descrição | add login page |
Primeira letra minúscula, sem ponto final |
| Tamanho do cabeçalho | No máximo 100 caracteres | |
| Rodapé | Closes #123 |
Depois de uma linha em branco |
O que é verificado. As doze regras do @commitlint/config-conventional: dez erros (tipo vazio, maiúsculas no tipo, lista de tipos, descrição vazia, maiúsculas na descrição, ponto final, tamanho do cabeçalho, espaços no cabeçalho, tamanho das linhas do corpo e do rodapé) e dois avisos (uma linha em branco antes do corpo e antes do rodapé). Cada falha é explicada em palavras simples, com a correção.
O salto de versão. A especificação relaciona os commits ao Versionamento Semântico (Semantic Versioning): fix significa uma versão patch, feat uma minor, e qualquer mudança incompatível, marcada com ! ou com um rodapé BREAKING CHANGE, uma major. Outros tipos, como docs ou chore, não mudam a versão sozinhos.
Um pull request inteiro. Mude para o modo de lista e cole a saída de git log --format=%s main..HEAD, um cabeçalho por linha. Cada cabeçalho passa ou falha, e a versão que resulta do conjunto é indicada.
As respostas foram conferidas com o @commitlint/lint 19 e o config-conventional em mais de 100 mensagens. Tudo roda no seu navegador; nada do que você digita é enviado para lugar nenhum.
Uma mensagem de commit cuja primeira linha é um tipo, um scope opcional entre parênteses, dois-pontos, um espaço e uma descrição curta, como fix(api): handle empty response. O formato vem da especificação Conventional Commits 1.0.0, e as ferramentas o usam para escolher o próximo número de versão e escrever changelogs automaticamente.
Use feat para uma mudança que os usuários veem como um recurso novo, fix para a correção de um bug e chore para manutenção que não muda nenhum dos dois, como atualizar dependências. As versões decorrem deles: feat gera uma versão minor, fix um patch e chore nenhuma versão sozinho. docs, style, refactor, perf, test, build e ci são os outros tipos padrão.
Coloque um ponto de exclamação antes dos dois-pontos, como em feat(api)!: remove the v1 endpoints, ou adicione depois de uma linha em branco um rodapé que comece com BREAKING CHANGE: e diga o que quebra. Qualquer um dos dois torna a versão major, seja qual for o tipo. Os dois juntos são permitidos e comuns.
Geralmente porque o cabeçalho não segue exatamente type: description, então o commitlint não encontra nem um tipo nem uma descrição. Causas comuns são a falta de espaço depois dos dois-pontos, um espaço antes deles, um tipo com maiúscula ou desconhecido, ou nenhum tipo. Cole a mensagem aqui para ver qual parte foi mal interpretada.
Não com o config-conventional: a regra subject-case dele rejeita descrições em sentence case, start case, pascal case ou upper case, então Add login falha e add login passa. Texto entre crases ou aspas é ignorado por essa regra, então um nome como `Button` no início não tem problema. Equipes que querem maiúsculas mudam a regra na própria configuração.
Não. Por padrão, o commitlint ignora commits de merge, reverts escritos pelo git, commits fixup! e squash!, e cabeçalhos que são apenas um número de versão, como 1.2.3 ou chore(release): 1.2.3. Esta página ignora as mesmas mensagens e avisa, de modo que uma verificação aqui dá a mesma resposta que o hook.
Taxas e regras mudam; confira a fonte antes de confiar em um valor.
Ainda com dúvidas? Pergunte sobre Validador de Conventional Commits e qualquer pessoa que saiba pode responder. Não é preciso ter conta.