Overview
Introduction
Conventional Commits is simple in theory, but getting the exact punctuation right, where the `!` goes, whether scope is in parentheses before or after the colon, how the breaking-change footer is worded, is easy to fumble when typing a commit message quickly.
This tool builds a correctly formatted Conventional Commits message from separate type, scope, subject, body, and breaking-change fields, so the punctuation and structure are always right.
What Is Conventional Commit Message Generator?
A form-driven builder for Conventional Commits messages. You choose a type (feat, fix, chore, docs, refactor, test, perf), optionally add a scope and a longer body, write a subject line, and optionally mark the commit as a breaking change with a description.
The output is the complete commit message text, ready to paste into `git commit -m` (for a single-line message) or a commit message editor for the full multi-paragraph version.
How Conventional Commit Message Generator Works
The header line is assembled as `type(scope)!: subject`, only including the scope's parentheses if you provided one, and only appending `!` if the breaking-change toggle is on.
If you provide a body, it's added after a blank line following the header; if breaking change is enabled, a `BREAKING CHANGE: <description>` footer is appended after its own blank line, matching the spec's required footer format.
When To Use Conventional Commit Message Generator
Use it for any commit in a repository that follows (or is adopting) Conventional Commits, especially one using automated tooling like semantic-release, commitlint, or auto-generated changelogs that depend on the format being exactly right.
It's also useful for teaching Conventional Commits to a team, since seeing the fields map directly to the assembled message output makes the format concrete.
Often used alongside Release Notes Generator, Git Hooks Generator and GitHub Actions Workflow Generator.
Features
Advantages
- Guarantees correct punctuation (parentheses, the breaking-change `!`, footer formatting) every time, rather than relying on manual memory of the spec's exact syntax.
- Validates subject length and trailing-period conventions before generating, catching common commitlint violations before you even try to commit.
- Produces a message ready to paste directly into `git commit -m "..."` or a commit editor without further editing.
Limitations
- Only supports a single scope and a single breaking-change footer; commits needing multiple footers (like a `Refs:` or `Co-authored-by:` trailer) need those added manually afterward.
- Doesn't validate that the described type actually matches your changes, that judgment call is still up to you.
Examples
Best Practices & Notes
Best Practices
- Keep the subject line under about 50-72 characters where possible so it displays cleanly in `git log --oneline` and most Git UIs.
- Use the body to explain why a change was made, not just what changed, the diff already shows what changed.
- Reserve breaking-change commits for genuinely breaking changes, marking too many commits as breaking dilutes the signal semantic-release and changelog tools rely on.
Developer Notes
The header is assembled as a single template string with each optional segment (scope parentheses, breaking `!`) conditionally included based on whether the corresponding field was provided, exactly matching the Conventional Commits v1.0.0 grammar: `type(scope)!: description`. Validation rejects a trailing period on the subject and enforces a 100-character ceiling as a practical safety net, though the spec itself doesn't mandate a specific length limit.
Conventional Commit Message Generator Use Cases
- Writing individual commits in a repository using semantic-release or another Conventional-Commits-aware changelog tool
- Teaching a team the Conventional Commits format with a concrete field-to-output mapping
- Drafting a properly formatted breaking-change commit message before making an API change
Common Mistakes
- Putting the breaking-change `!` after the scope's closing parenthesis instead of immediately before the colon (or omitting it entirely while still writing a BREAKING CHANGE footer), which some tooling won't reliably detect as breaking.
- Writing a vague BREAKING CHANGE description like "changed the API" instead of specifying exactly what changed and how consumers should migrate.
Tips
- Pair this with a commit-msg Git hook (see the Git Hooks Generator) that runs commitlint, so malformed commit messages are caught locally before they're pushed.