QiLing Tools

📜Conventional Commits Generator - Well-Formed Git Messages

The annoying part of adopting Conventional Commits is remembering which types exist, where the exclamation mark goes and which paragraph the BREAKING CHANGE footer belongs in. This generator turns the spec into a form: pick a type, write the summary, add a body or a breaking change if you need one, and the message assembles itself — along with a git commit command you can paste straight into a terminal and a warning when the header passes 72 characters.

Free · No sign-up · Runs in your browserLast updated:

Loading tool...

How to use Commit message

  1. 1Pick a type; the page tells you how it affects the version number
  2. 2Add a scope and a summary (imperative, present tense, no full stop)
  3. 3Add a body, breaking change and related issues if needed
  4. 4Copy the message, or copy the whole git commit command

FAQ

Who defines these types?
The Conventional Commits spec itself only defines feat and fix; the rest (docs, style, refactor, perf, test, build, ci, chore, revert) come from the Angular convention and have become the de facto standard. Teams can add or drop types — consistency matters more than the list.
How does the type change the version?
With a tool like semantic-release: fix bumps the patch version (0.1.0 → 0.1.1), feat bumps the minor (0.1.0 → 0.2.0), and a ! or BREAKING CHANGE bumps the major (1.2.0 → 2.0.0). Other types release nothing by default.
Why limit the header to 50 or 72 characters?
git log --oneline, GitHub lists and mail notifications all show one line and truncate the rest. 50 was Linus's suggestion, 72 is the usual mail body width; this tool warns at 72.
Can I write the message in another language?
Yes — the spec only constrains the type and structure, not the prose. Just watch the width: CJK characters take two columns in a terminal.