Build a clean Conventional Commit message field by field: type, optional scope, a short imperative subject, a wrapped body, a BREAKING CHANGE note and issue references. Every rule is checked as you type, and you can copy the message or a ready-to-run git commit command.
Last updated:
0
Imperative, lower case, no full stop. Complete the sentence "If applied, this commit will …"
Commit message
Checks
Result
Advertisement
Advertisement
How to use the Commit Message Generator
Pick the type that matches the change: feat for a new feature, fix for a bug fix, docs, refactor, and so on.
Add a scope (optional) such as api, auth or ui to say which part of the code changed.
Write the subject in the imperative mood, lower case and without a full stop: "add password reset", not "Added password reset."
Explain why in the body if the change needs context, then tick Breaking change and describe what users must do if the change is not backward compatible.
Add issue references, review the checks, and copy the message or the git commit command.
Header: the only required line. A type, an optional scope in brackets, an optional ! for breaking changes, a colon, a space and a short description.
Body: free text after one blank line. Explain what changed and why, not how; the diff already shows how.
Footers: after another blank line, one per line in Token: value or Token #value form, such as BREAKING CHANGE: …, Refs: #123 or Co-authored-by: Name <email>.
Types and version bumps
Type
Use it for
Example
SemVer bump*
feat
New functionality for users
feat(cart): add coupon field
Minor (1.4.0 → 1.5.0)
fix
Bug fixes
fix(api): return 404 for unknown ids
Patch (1.4.0 → 1.4.1)
perf
Speed or memory improvements
perf: cache parsed templates
Patch
refactor
Restructuring without changing behaviour
refactor(db): extract query builder
None
docs
Documentation only
docs: explain env variables in README
None
style
Formatting, white space, linting fixes
style: apply prettier to src
None
test
Adding or fixing tests
test(auth): cover expired tokens
None
build
Build tools and dependencies
build(deps): bump vite to 5.4
None
ci
CI pipelines and scripts
ci: cache npm in GitHub Actions
None
chore
Maintenance that touches no source or tests
chore: update .editorconfig
None
revert
Undoing an earlier commit
revert: feat(cart): add coupon field
Depends
any type + ! or BREAKING CHANGE:
Changes that are not backward compatible
feat(api)!: drop v1 endpoints
Major (1.4.0 → 2.0.0)
*Default behaviour of semantic-release and standard-version with the Angular / conventional preset. Many teams configure perf, refactor or docs differently.
Length rules this tool checks
50 characters for the header is the classic guideline (from the Git project and "How to Write a Git Commit Message"): it fits in git log --oneline, GitHub commit lists and email subjects.
72 characters is the usual hard limit for the header and the wrap width for body lines, because git log indents the body by 4 spaces and should still fit an 80-column terminal.
100 characters is commitlint's default header-max-length and body-max-line-length in @commitlint/config-conventional; longer lines fail the lint. URLs are not counted, since they can't be wrapped.
Tip: if the subject needs the word "and", the commit probably does two things. Splitting it makes reviews, reverts and git bisect easier. For the Git commands to amend, squash or reword a commit, see the Git Cheat Sheet.
Frequently asked questions
What is a Conventional Commit?
Conventional Commits is a lightweight specification for commit messages. The first line has the form type(scope): description, for example fix(parser): handle empty input. Optional body and footer paragraphs follow after a blank line. The structure lets tools generate changelogs and decide semantic version bumps automatically.
Which commit types can I use?
The specification itself only defines feat and fix. The widely used commitlint config-conventional preset, based on the Angular convention, also allows build, chore, ci, docs, perf, refactor, revert, style and test. Those 11 types are offered here.
How do I mark a breaking change?
Add an exclamation mark before the colon, as in feat(api)!: remove v1 endpoints, and/or add a footer that starts with BREAKING CHANGE: followed by a description. A breaking change triggers a major version bump in semantic-release and similar tools, whatever the commit type.
How long should a commit subject be?
Aim for 50 characters or less in the whole first line so it is fully visible in git log --oneline, GitHub and most tools. 72 characters is a common hard limit, and commitlint's default header-max-length is 100. Body lines are usually wrapped at 72 characters.
Why write the subject in the imperative mood?
Git itself writes messages like Merge branch 'x' and Revert 'y', so a subject that completes the sentence 'If applied, this commit will ...' reads consistently: 'add login form', not 'added login form' or 'adds login form'.
How do I close a GitHub or GitLab issue from a commit?
Put a closing keyword and the issue number in the footer, for example Closes #42 or Fixes #42. GitHub closes the issue when the commit reaches the default branch; GitLab supports the same keywords. Refs #42 links the issue without closing it.
How do I use a multi-line message with git commit?
Each -m flag becomes its own paragraph separated by a blank line, so git commit -m 'header' -m 'body' -m 'footer' produces a correctly formatted message. The generated command uses this form with safe quoting for Bash or PowerShell.
Are all the tools on FreeToolCabin tested for quality and accuracy?
Yes! Every tool on our site undergoes automated Q/A testing in real browser environments to ensure high precision, correct output, and zero errors. If you happen to spot a bug or have a suggestion, please contact us at [email protected] and our team will review it right away.