Como usar: Conventional Commit Builder
- Pick the type of change —
featfor a new feature,fixfor a bug fix, or docs, refactor, perf, test, build, ci, chore, style or revert. - Add an optional scope (the part of the code it touches) and a short description in the imperative: “add”, not “added”.
- Explain what and why in the body; tick Breaking change and describe the migration if users must change something.
- Add footers such as
Closes #123, fix anything the checks flag, then copy the message or thegit commitcommand.
The Conventional Commits format
<type>[optional scope][!]: <description>
[optional body]
[optional footer(s)]| Type | Use it for | Version bump |
|---|---|---|
feat | A new feature | Minor (1.4.0 → 1.5.0) |
fix | A bug fix | Patch (1.4.0 → 1.4.1) |
! or BREAKING CHANGE: | A change users must adapt to | Major (1.4.0 → 2.0.0) |
| docs, style, refactor, perf, test, build, ci, chore, revert | Everything else | None (unless breaking) |
Tools such as semantic-release, release-please and standard-version read these messages to choose the next version and write the changelog automatically; commitlint enforces them in CI or a git hook. Keep the header under 72 characters, start the description in lowercase with an imperative verb, and don’t end it with a period. Generate a changelog with the Changelog Generator and other git commands with the Git Command Generator.
Também pesquisado como: conventional commits, conventional commit generator, commit message generator, git commit message format, semantic commit messages, commitlint, feat fix commit, breaking change commit.
Ferramentas que combinam com: Conventional Commit Builder
- Semantic Version Calculator — Everything about semantic versions in one place: compare two versions, calculate the next major/minor/patch/prerelease, and see exactly which versions an npm range like ^1.2.0 or ~2.3 allows — explained in plain English.
- Git Cheat Sheet — Every Git command you use day to day — and the ones you need when something goes wrong — explained in one line.
- Gerador de fluxos de trabalho do GitHub Actions — Escolha sua pilha, gatilhos e etapas e receba um arquivo .github/workflows/ci.yml — instalação, cache, verificação de código, teste, compilação, uma matriz de versões e, opcionalmente, implantação no GitHub Pages, Vercel ou em um registro de contêineres.
- LICENSE File Generator — Add the right open-source license to your project in seconds.
Perguntas frequentes
What is a conventional commit?
A commit message in the format type(scope): description — for example fix(auth): handle expired tokens — that tools can read to decide version numbers and build changelogs.
How do I mark a breaking change?
Add ! after the type or scope (feat(api)!: …) and a BREAKING CHANGE: footer that explains what changed. Tick Breaking change here to get both.
What is the difference between chore and refactor?
refactor changes code structure without changing behavior; chore covers maintenance that doesn’t touch source behavior, like updating dependencies or tooling config.
How do I write a multi-line commit message from the command line?
Use one -m per paragraph: git commit -m "header" -m "body" -m "footer". The git command here does that for you, with quotes escaped.
Posso instalar o Conventional Commit Builder como um aplicativo da web e usá-lo offline?
Sim. O Conventional Commit Builder é um aplicativo da web instalável (PWA) — instalado a partir do seu navegador, não baixado de uma loja de aplicativos. Clique em “Instalar aplicativo” na parte superior desta página no Chrome ou no Edge (Windows, macOS, Linux, ChromeOS) ou, no Android, use “Compartilhar” → “Adicionar à tela inicial” no iPhone e no iPad, ou “Arquivo” → “Adicionar ao Dock” no Safari 17+ em um Mac. Em seguida, ela se abre em uma janela própria com seu próprio ícone e, como é executada inteiramente no seu navegador, continua funcionando offline. O Firefox no desktop não permite a instalação de aplicativos da web. Como funciona a instalação.