Formatador de Mensagem de Commit Convencional
Crie uma mensagem Conventional Commits compatível com a especificação a partir de um tipo, escopo e descrição, ou cole uma mensagem de commit existente para analisá-la em suas partes. Rastreia o limite de 72 caracteres da linha de assunto e adiciona automaticamente um rodapé BREAKING CHANGE.
Entrada
Área opcional da base de código que essa mudança afeta.
Resumo curto no modo imperativo, sem ponto final.
Saída
| Verificação | Resultado |
|---|---|
| No data yet | |
Mais formas de usar esta ferramenta
API REST
curl -X POST https://api.iotools.cloud/v1/tool/conventional-commit-message-formatter \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"mode": "build",
"type": "feat",
"scope": "auth",
"description": "add OAuth2 login support",
"breaking": "true",
"breakingDescription": "The login() function now requires an options obj…",
"body": "Implements the OAuth2 authorization code flow us…",
"footers": "Refs: #482"
}'Troque pela sua própria chave, da sua conta. Os campos da ferramenta viram o corpo da requisição — sem envelope.
Peça a um agente de IA
Use the IOTools `conventional-commit-message-formatter` tool (Conventional Commit Message Formatter) on this input:
YOUR_INPUT_HERECole isto em qualquer agente conectado ao servidor MCP do IOTools e depois adicione sua entrada.
Widget para incorporar
<iframe
src="https://iotools.cloud/embed/conventional-commit-message-formatter/"
width="100%" height="520" frameborder="0" scrolling="no" loading="lazy"
title="Formatador de Mensagem de Commit Convencional — iotools.cloud"
sandbox="allow-scripts allow-forms allow-same-origin allow-downloads allow-popups allow-popups-to-escape-sandbox"
allow="clipboard-write"
style="width:100%;border:1px solid #e5e7eb;border-radius:12px;overflow:hidden"></iframe>
<script src="https://iotools.cloud/embed.js" async></script>Coloque isso na sua própria página — grátis, sem chave, só um link de volta.
| Custo por chamada de API/MCP | A partir de 5 créditos |
|---|---|
| Precisa de mais créditos? | Ver preços |
Também disponível via
Guias
Conventional Commits é um formato rígido,
legível por máquina, para mensagens de commit: um tipo, um escopo opcional, uma
descrição curta e seções opcionais de corpo/rodapé. Ferramentas como commitlint,
semantic-release e geradores de changelog automatizados analisam essa mesma forma
exata — um caractere fora do lugar (dois pontos faltando, um espaço extra, sintaxe de
rodapé errada) e o commit falha silenciosamente na validação ou é pulado no changelog.
Esta ferramenta cria uma mensagem compatível com a especificação a partir de um
formulário para que o formato seja sempre correto, e também pode analisar uma mensagem
existente de volta para suas partes. Tudo é executado no seu navegador.
Como usar
- Selecione Criar mensagem.
- Escolha um Tipo (
feat,fix,docs, …) e, opcionalmente, um Escopo (a área da base de código afetada, por exemplo,apiouparser). - Escreva uma Descrição curta no modo imperativo ("adicione", não "adicionado").
- Marque Mudança que quebra compatibilidade se o commit quebra a compatibilidade
com versões anteriores e descreva a quebra — ela será adicionada como um rodapé
BREAKING CHANGE:e!após o tipo/escopo, exatamente como a especificação exige. - Adicione um Corpo opcional para uma explicação mais longa e Rodapés para
coisas como
Refs: #123ouReviewed-by: Name(um por linha). - Copie a mensagem formatada diretamente para
git commit -m "..."ou para a caixa de mensagem de commit do seu editor.
Alterne para Analisar mensagem para fazer o inverso: cole uma mensagem de commit existente e a ferramenta a divide de volta em tipo, escopo, sinalizador de mudança que quebra compatibilidade, descrição, corpo e rodapés — útil para verificar se uma mensagem escrita por outra pessoa realmente segue a especificação.
Comprimento da linha de assunto
A tabela Verificação da Linha de Assunto rastreia seu cabeçalho formatado (tipo(escopo)!: descrição) em relação ao limite de 72 caracteres comumente usado, para que linhas de
assunto longas que seriam truncadas em git log --oneline ou na lista de commits do
GitHub sejam capturadas antes de você fazer o commit.
Tipos de commit
feat e fix mapeiam diretamente para bumps de versão semântica em
Semantic Versioning quando uma ferramenta como semantic-release
lê seu histórico, e um rodapé BREAKING CHANGE (ou !) dispara um bump de versão
major independentemente do tipo. O restante — docs, style, refactor, perf,
test, chore, ci, build, revert — descreve a mudança sem afetar o número
da versão.
Isso substitui um hook de commit como commitlint?
Não — commitlint valida commits no momento do commit (geralmente via um hook Git) e é projetado para ser executado automaticamente no fluxo de trabalho de um time. Esta ferramenta é para escrever uma mensagem à mão ou para verificar uma mensagem antes de colá-la. Use ambas: esta para compor a mensagem, commitlint para aplicar a regra automaticamente.
E se eu precisar revisar um histórico de commit inteiro em vez de apenas uma mensagem?
Use Git Log Formatter / Prettifier para
transformar a saída git log em uma tabela, lista ou JSON — ou
Git Cheatsheet para comandos Git comuns.