Git Commit Message Generator

Generate standardized Conventional Commits with scope, breaking changes, Gitmoji, and ticket prefixes.

Sample Presets:

Commit Typefeat

Header Length0 / 72

Validation Health Perfect

Quick Copy

Commit Style / Prefix Format

Commit Type

Scope (optional)

Ticket ID (optional)

Breaking Change (! / BREAKING)

Short Description (Imperative mood)0/72 chars

Body (optional details/motivation)

Footer (optional, e.g. Closes #123)

Generated Commit Message

Select type and enter a short description above to generate commit message...

What is Conventional Commits?

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of (such as automatic semantic versioning and changelog generation). The structure is: type(scope): description followed by optional body and footers. Using standard types like feat, fix, refactor, and perf keeps project logs clear and maintainable.

Built and maintained by Meet Shah · Last updated 1 August 2026

What this tool is used for

Building a Conventional Commits message with the right structure.
Getting the breaking-change footer format right.
Producing a consistent message format across a team.
Writing a message with a body without remembering the blank-line rule.
Checking a message against the convention before committing.

Frequently Asked Questions

What is Conventional Commits?: A format — `type(scope): description` — with types like feat, fix, docs, refactor, test and chore. Its value is machine-readability: tooling can derive a changelog and a semantic version bump directly from the log rather than from a human's summary.
How does it drive versioning?: `fix` implies a patch bump, `feat` a minor, and a `BREAKING CHANGE` footer or a `!` after the type implies a major. That mapping is what makes automated releases possible, and it only works if the types are applied honestly.
Why is the imperative mood the convention?: Because git's own generated messages use it — "Merge branch", "Revert commit". A subject reading "Fix the parser" completes the sentence "this commit will…", which is the test for whether the mood is right.
Why 50 and 72 characters?: 50 for the subject so `git log --oneline` and GitHub's UI do not truncate it, and 72 for body lines so the message stays readable in an 80-column terminal after git's four-space indent. Both are conventions from the era of the terminal and both still bind.
What belongs in the body?: Why, not what — the diff already shows what changed. The body is for the reasoning, the alternatives rejected, and anything a reader six months later would need. That is the part a generated message cannot supply and the part that matters most.

Common errors and gotchas

Omitting the blank line between subject and body, which makes tooling treat the whole thing as a subject.
Using a type the project's own config does not allow, which a commit hook then rejects.
Writing a subject that describes the code rather than the change's effect.
Marking a change as a fix when it is a feature, which then affects the released version number.
Putting the breaking-change note in the body rather than the footer, where tooling looks for it.