What is the Conventional Commits format?

It is a lightweight convention of `type(scope): subject`, with an optional body and footers. The structured prefix lets tools derive changelogs and semantic-version bumps automatically from your history.

How do I mark a breaking change?

Add a `!` after the type or scope and include a `BREAKING CHANGE:` footer describing the impact. Either signal tells release tooling to bump the major version, and the builder adds both when you tick the box.

Which types should I use?

Common types are feat, fix, docs, style, refactor, perf, test, build, ci, chore, and revert. feat and fix map to minor and patch version bumps; the rest document intent without forcing a release.

How long should the subject line be?

Keep the whole header under about 50 characters and never past 72, written in the imperative mood with no trailing full stop. The builder shows a live count and warns when the header grows too long.

Do I need a body for every commit?

No. Trivial changes are fine with just a header. Add a body when the why is not obvious from the subject, wrapping lines around 72 characters and explaining motivation rather than restating the diff.

Git Commit Message Builder

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

Conventional commits without memorising the spec

Conventional Commits turn your git history into something tools can read — auto-generated changelogs and automatic semantic-version bumps — but only if every message follows the format precisely. This builder walks you through type, scope, subject, body, breaking changes, and issue references, then assembles a message that parses cleanly.

How it works

The output follows the type(scope): subject header rule. The type classifies the change (feat and fix drive minor and patch bumps; docs, refactor, chore and others document intent). An optional scope in parentheses names the affected area. The subject is your imperative one-liner. When you flag a breaking change, the builder appends ! to the header and adds a BREAKING CHANGE: footer — both recognised signals for a major-version bump. Issue numbers become a Closes #123 footer. A live counter checks the header length against the 50/72-character guidance so the first line stays readable in tools and git log.

Tips and example

Write the subject as a command: “add retry to upload”, not “added” or “adds”.
Use a scope to disambiguate large repos: fix(auth): handle expired refresh token.
Put the why in the body and the what in the diff — reviewers can already see the code change.
For a reverting commit, choose the revert type and reference the original commit hash in the body.