Gerador de mensagem de commit (Conventional Commits)
Escolha o tipo, escreva a descrição e copie a mensagem pronta e o comando git commit. Confere a mensagem contra as 16 regras da especificação 1.0.0.
Dentro do padrão Conventional Commits 1.0.0
O que você mudou
Tipo definido nas regras da especificação.
Um substantivo que diz a parte do projeto: readme, cli, api.
Diga o que a mudança faz, no presente, sem ponto final. Cerca de 50 caracteres cabem bem na primeira linha.
Corpo da mensagem. Explique o motivo e o que você conferiu. Linhas em branco separam parágrafos.
Só o número. Vira o rodapé Closes #número; o GitHub fecha a issue quando o pull request vai para a branch padrão.
Um por linha, no formato Token: valor. Troque espaços do token por hífen (Reviewed-by).
Suas escolhas ficam só neste navegador, para você não redigitar. Nada é enviado.
Como escrever uma mensagem de commit no padrão Conventional Commits?
Comece com o tipo, um escopo opcional, um ! opcional, dois-pontos e um espaço, e escreva a descrição: por exemplo, fix(parser): corrige a leitura de datas. Corpo e rodapés são opcionais.
Tipos de commit: o que é regra e o que é costume
| Tipo | Quando usar | Efeito na versão | Origem |
|---|---|---|---|
feat | Acrescenta uma funcionalidade nova. | MINOR | regras 2 e 3 |
fix | Corrige um defeito. | PATCH | regras 2 e 3 |
docs | Muda só documentação (README, comentários, guias). | nenhum (a menos que haja quebra) | exemplo da regra 14 |
style | Muda formatação, sem mudar o comportamento. | nenhum (a menos que haja quebra) | lista do @commitlint/config-conventional, citada na especificação |
refactor | Reorganiza o código sem corrigir defeito nem acrescentar funcionalidade. | nenhum (a menos que haja quebra) | lista do @commitlint/config-conventional, citada na especificação |
perf | Melhora o desempenho. | nenhum (a menos que haja quebra) | lista do @commitlint/config-conventional, citada na especificação |
test | Cria ou ajusta testes. | nenhum (a menos que haja quebra) | lista do @commitlint/config-conventional, citada na especificação |
build | Muda o sistema de build ou as dependências. | nenhum (a menos que haja quebra) | lista do @commitlint/config-conventional, citada na especificação |
ci | Muda a integração contínua (workflows, pipelines). | nenhum (a menos que haja quebra) | lista do @commitlint/config-conventional, citada na especificação |
chore | Tarefa de manutenção que não cabe nos outros tipos. | nenhum (a menos que haja quebra) | lista do @commitlint/config-conventional, citada na especificação |
A especificação só define dois tipos: feat e fix. Os demais são permitidos pela regra 14, e a lista de oito tipos aparece nela como a que o pacote @commitlint/config-conventional recomenda. Se o seu projeto usa outro conjunto, o gerador aceita qualquer tipo digitado no validador e apenas avisa quando ele não está na lista. A coluna “Efeito na versão” segue o versionamento semântico: feat soma ao MINOR, fix ao PATCH, e qualquer quebra de compatibilidade ao MAJOR.
O que é regra e o que é regra prática
O gerador e o validador separam três níveis de achado. Erro é o que contraria uma regra numerada da especificação, como faltar o espaço depois dos dois-pontos ou escrever breaking change: em minúsculas no rodapé. Aviso é o que a especificação permite, mas costuma ser engano: um tipo em maiúsculas, um tipo fora da lista ou um token de rodapé com espaço. Dica é regra prática regra prática, sem fonte oficial, como manter a primeira linha em cerca de 50 caracteres, sugestão do livro Pro Git, ou não terminar a descrição com ponto final. As dicas nunca invalidam a mensagem.
A lista completa do Pro Git sobre mensagens está no guia como escrever uma boa mensagem de commit, e o que fazer quando um rodapé como Closes #42 aparece no pull request está em como abrir um pull request de um fork.
O que não foi confirmado: a lista de tipos que ferramentas como o commitlint aceitam hoje, porque só abrimos a página da especificação. não confirmado
Já escreveu a mensagem? Cole para conferir
O validador lê a mensagem e aponta a regra da especificação que ela contraria. O texto colado não é guardado nem enviado.
Para conferir uma mensagem que você já escreveu. O texto colado não é guardado.
O resultado aparece aqui.
As 16 regras da especificação 1.0.0
Resumo próprio em português; a frase da especificação está no original, em inglês, com a fonte ao lado.
| Regra | Em resumo | No original (conventionalcommits.org) |
|---|---|---|
| 1 | A mensagem começa com um tipo (um substantivo, como feat ou fix), escopo opcional, um ! opcional e, obrigatoriamente, dois-pontos e um espaço. | “Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.” |
| 2 | O tipo feat é obrigatório para quem acrescenta uma funcionalidade. | “The type feat MUST be used when a commit adds a new feature to your application or library.” |
| 3 | O tipo fix é obrigatório para quem corrige um defeito. | “The type fix MUST be used when a commit represents a bug fix for your application.” |
| 4 | O escopo, se existir, é um substantivo entre parênteses logo depois do tipo. | “A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):” |
| 5 | A descrição vem logo depois de "dois-pontos e espaço" e resume a mudança. | “A description MUST immediately follow the colon and space after the type/scope prefix.” |
| 6 | Um corpo pode vir depois da descrição, e começa depois de uma linha em branco. | “A longer commit body MAY be provided after the short description… The body MUST begin one blank line after the description.” |
| 7 | O corpo é livre e pode ter vários parágrafos. | “A commit body is free-form and MAY consist of any number of newline separated paragraphs.” |
| 8 | Rodapés vêm depois do corpo, separados por uma linha em branco; cada um é um token, o separador ": " ou " #" e um valor. | “One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value.” |
| 9 | O token do rodapé troca espaços por hífen (Reviewed-by). A exceção é BREAKING CHANGE. | “A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by… BREAKING CHANGE MAY also be used as a token.” |
| 10 | O valor do rodapé pode ter espaços e quebras de linha; o rodapé termina quando aparece o próximo par token e separador. | “A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.” |
| 11 | Mudança que quebra compatibilidade vai no prefixo (!) ou em um rodapé BREAKING CHANGE. | “Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.” |
| 12 | No rodapé, BREAKING CHANGE é em maiúsculas, seguido de dois-pontos, espaço e a descrição. | “If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description.” |
| 13 | No prefixo, o ! vem logo antes dos dois-pontos. Com ele, o rodapé BREAKING CHANGE pode ser omitido e a descrição passa a explicar a quebra. | “If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.” |
| 14 | Outros tipos além de feat e fix são permitidos (a especificação dá docs como exemplo). | “Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.” |
| 15 | Maiúsculas e minúsculas não importam, exceto em BREAKING CHANGE, que é sempre em maiúsculas. | “The units of information that make up Conventional Commits MUST NOT be treated as case sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.” |
| 16 | No rodapé, BREAKING-CHANGE (com hífen) vale como sinônimo de BREAKING CHANGE. | “BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.” |
Fonte: Conventional Commits 1.0.0, licença CC BY 3.0, aberta em 11/10/2026. A página não mostra data. Os trechos em inglês são frases curtas das regras, com a fonte e a licença ao lado.
Perguntas frequentes
O que é o Conventional Commits?
É uma especificação, na versão 1.0.0, para mensagens de commit no formato tipo(escopo): descrição, com corpo e rodapés opcionais. A especificação liga feat ao número MINOR e fix ao PATCH do versionamento semântico. O validador abaixo do gerador confere uma mensagem contra as 16 regras.
Quais tipos posso usar?
A especificação define feat e fix e diz que outros tipos podem ser usados. A lista build, chore, ci, docs, style, refactor, perf e test aparece nela como a recomendada pelo @commitlint/config-conventional. O gerador marca qual tipo vem das regras e qual vem dessa lista.
Como funciona o comando git commit gerado?
Cada parágrafo da mensagem vira um -m, e o Git os junta separados por uma linha em branco. O texto vai entre aspas simples, para o terminal não mexer nele. Você pode escolher a versão para Bash ou para PowerShell. Foi testado nos dois: o commit gravado é idêntico à mensagem.
O limite de 50 caracteres é uma regra?
Não. A especificação não fixa tamanho. O Pro Git sugere cerca de 50 caracteres no resumo, e este site mostra isso como dica rotulada de regra prática, nunca como erro.
A mensagem é enviada a algum lugar?
Não. Tudo roda no seu navegador. O que você digita no gerador fica guardado só no armazenamento local, para não precisar redigitar, e o texto colado no validador nem isso: some quando você fecha a página.
Fontes desta página
Abertas em 11/10/2026. Nenhuma das páginas mostra data.
- Conventional Commits 1.0.0 (conventionalcommits.org)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 3.0
O que lemos: As 16 regras numeradas (tipo, escopo, ! , descrição, corpo, rodapés, BREAKING CHANGE), a ligação entre feat e fix e os números MINOR e PATCH do SemVer, a lista de tipos recomendada pelo @commitlint/config-conventional e os exemplos. A versão exibida é a 1.0.0; a página não marca nenhuma versão mais nova.
Como usamos: As regras são resumidas em português e citadas por número. Os trechos em inglês são curtos, de regras, com a fonte ao lado. - Conventional Commits 1.0.0, em português do Brasil (conventionalcommits.org)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 3.0
O que lemos: Confirmei que existe a tradução em português do Brasil da versão 1.0.0 e que ela traz a mesma licença no rodapé.
Como usamos: Só link, para quem prefere ler em português. - Pro Git, 5.2 Git Distribuído: Contribuindo com um Projeto (git-scm.com)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY-NC-SA 3.0
O que lemos: As diretrizes de commit: conferir espaços em branco com git diff --check, um commit por mudança lógica, resumo de cerca de 50 caracteres, linha em branco e explicação por volta de 72 colunas, verbo no imperativo.
Como usamos: Só link e fatos (git diff --check; limites de 50 e 72 caracteres, tratados aqui como regra prática). Nenhum trecho do livro é copiado ou adaptado, por causa da cláusula NC. - Versionamento Semântico 2.0.0 (semver.org)
A página não mostra data · aberta em · reconferência: confirmada na abertura (11/10/2026) · licença do conteúdo: CC BY 3.0
O que lemos: As 11 regras da versão 2.0.0 (API pública, X.Y.Z, versão lançada não muda, 0.y.z, pré-lançamento com hífen, metadados com +, precedência) e o resumo MAJOR, MINOR e PATCH.
Como usamos: Resumo próprio das regras, em português, com o número da regra. O texto da especificação não é reproduzido.
Continue por aqui
Os geradores, o passo a passo e os guias ficam a um clique.
- Primeira contribuiçãoDo fork ao pull request, com os comandos de git para copiar.
- Gerador de READMEPreencha o projeto e copie o README.md pronto.
- Gerador de CONTRIBUTINGDiga como o projeto recebe ajuda e copie o arquivo.
- Praticar no terminalTerminal de faz de conta: do clone ao push, sem mexer em repositório de verdade.
- Guias16 guias curtos, cada um com a fonte oficial aberta e a licença.