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.

What is the Git Commit Message Builder?

Guides you through the Conventional Commits format — type (feat, fix, docs, chore and more), optional scope, imperative subject, body, breaking-change footer, and issue references — and outputs a correctly formatted commit message with a live header length check. It runs free in your browser on Gera Tools, with nothing uploaded.

Git Commit Message Builder

Name: Git Commit Message Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click 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.

The commit types and what they mean

Type	SemVer impact	Use for
`feat`	Minor bump	A new user-facing feature
`fix`	Patch bump	A bug fix
`docs`	None	Documentation changes only
`style`	None	Formatting, whitespace — no logic change
`refactor`	None	Code restructuring with no feature or fix
`perf`	None	Performance improvements
`test`	None	Adding or updating tests
`build`	None	Build system or dependency changes
`ci`	None	CI configuration changes
`chore`	None	Maintenance tasks, tooling
`revert`	Depends	Reverting a prior commit

Breaking changes

A breaking change is any change that forces callers or users to update their code. Signal it two ways: add ! after the type/scope in the header, and add a BREAKING CHANGE: footer explaining what changed and how to migrate. Tools like semantic-release and standard-version treat either signal as a major-version bump.

For example:

feat(api)!: remove deprecated /v1/users endpoint

BREAKING CHANGE: /v1/users has been removed. Use /v2/users instead.
Closes #89

Complete example with body

fix(auth): retry token refresh on network timeout

The refresh step failed silently on flaky connections, logging users
out unnecessarily. Added exponential backoff with three attempts before
propagating the error.

Closes #234

The header is 51 characters — within the 72-character limit. The body explains the why rather than the what. The Closes footer links the commit to the issue tracker so the issue auto-closes on merge.

Tips

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.
Keep chore for true housekeeping only; if you upgraded a dependency to fix a security flaw, use fix so the patch release is tagged.