How to use the 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.
Also searched as: conventional commits, conventional commit generator, commit message generator, git commit message format, semantic commit messages, commitlint, feat fix commit, breaking change commit.
Tools that pair well with the 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.
- GitHub Actions Workflow Generator — Choose your stack, triggers and steps and get a commented .github/workflows/ci.yml — install, cache, lint, test, build, a version matrix and optional deploy to GitHub Pages, Vercel or a container registry.
- LICENSE File Generator — Add the right open-source license to your project in seconds.
- YAML Validator — Paste a Docker Compose file, Kubernetes manifest, GitHub Actions workflow or any YAML to pinpoint errors, catch common pitfalls and get a cleanly formatted version.
Frequently asked questions
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.
Can I install Conventional Commit Builder as a web app and use it offline?
Yes. Conventional Commit Builder is an installable web app (PWA) — installed from your browser, not downloaded from an app store. Click Install app at the top of this page in Chrome or Edge (Windows, macOS, Linux, ChromeOS) or on Android, use Share → Add to Home Screen on iPhone and iPad, or File → Add to Dock in Safari 17+ on a Mac. It then opens in its own window with its own icon, and because it runs entirely in your browser it keeps working offline. Firefox on desktop can’t install web apps. How installing works.