Git Commit Message Helper
Turn a change summary into a clean, structured commit message — Conventional Commits or your own project style, validated as you type, 100% in your browser.
Describe what you changed, pick the type and scope, and this helper assembles a well-formed commit message while checking it against the rules your project lives by — subject length, imperative mood, valid types, breaking-change markers and footer references. Switch to the Check tab to lint an existing message and see exactly what its parts are.
1. Your change
The first line becomes the subject line. The rest is treated as the body.
2. Project style
Match your repo's convention. Pick a preset or set your own — the message and validation update live.
Placeholders: {type} {scope} (becomes (scope)) {breaking} (becomes !) {subject}
3. Your commit message
The command uses one -m for the subject and one for the body, so line breaks survive the shell.
Paste a commit message to inspect
Paste the full message (subject, body and footer). It's parsed into its parts and checked against the Conventional Commits rules below.
Conventional Commits, in brief
The Conventional Commits specification gives commit messages a predictable shape:
type(scope): subject, with an optional body and footer. Tooling like
standard-version and semantic-release reads that shape to auto-generate
changelogs and bump your version number — a feat is a minor release, a fix a
patch, and a ! or BREAKING CHANGE footer a major. Well-formed messages make that
automation reliable instead of guesswork.
The types
| Type | Use it for | Example |
|---|
Subject line rules
- Use the imperative mood — write it like a command:
add, notaddedoradds. Read as “If applied, this commit will add…” - Keep it under 50 characters (the default here) so it fits in
git log --onelineand GitHub's commit list. - Don't end it with a period.
- State what changed and why in the body — wrap at 72 columns so it reads cleanly in a terminal.
- Reference issues in the footer:
Closes #123,Fixes #456,Refs: PROJ-789. - For breaking changes, mark the type with
!and explain in aBREAKING CHANGE:footer.
Suggested
