Git Commit Message Generator

What the Conventional Commits format encodes

A Conventional Commit is a plain git message that follows one strict shape so that both humans and tooling can parse it. This generator assembles that shape for you: <type>(scope)!: description, optionally followed by a body and footers. The first line — the subject — is the part everything else keys off. The structured prefix turns a free-form sentence into machine-readable metadata: release tools can read it to bump version numbers automatically, and changelog generators can group commits by type without a human sorting them.

The tool offers the ten standard types, each with a one-line meaning so you never have to guess which to pick:

How type maps to Semantic Versioning

The format is not cosmetic — it drives version numbers. Under SemVer, feat warrants a MINOR bump (a new backward-compatible capability, e.g. 1.4.0 → 1.5.0), fix warrants a PATCH bump (1.4.0 → 1.4.1), and a BREAKING CHANGE warrants a MAJOR bump (1.4.0 → 2.0.0). The remaining types do not, by default, trigger a release. This is exactly why marking the breaking-change box does two things at once: it appends a ! after the scope and adds a BREAKING CHANGE: footer, both of which automated release tools look for to know they must bump the major version.

A worked example

Pick the feat type, type auth in the scope (or click the suggested auth chip), and write the description add OAuth login. The live preview immediately renders feat(auth): add OAuth login. Now tick "Use emoji prefix" and it becomes ✨ feat(auth): add OAuth login. Tick "Breaking change", fill in the breaking description session cookie renamed, and add 123 in the issue field. The full message becomes:

• ✨ feat(auth)!: add OAuth login
• (blank line, then) BREAKING CHANGE: session cookie renamed
• (blank line, then) Closes #123

Note the issue handling: you can type 123 or #123 and the tool normalises either to Closes #123, and a comma-separated list like 123, 456 produces one Closes line each.

Scope, body, and footers

The scope in parentheses names the part of the codebase a change touches — feat(api), fix(parser) — and is optional but invaluable in larger repositories, because it lets a reader filter the history to just the area they care about. To save typing, the tool offers context-aware scope chips: select fix and it suggests auth, parser, config, api, ui, db; select docs and it suggests readme, changelog, license. Click a chip to fill the field instantly. Below the subject, the optional body is where the "why" lives — a subject states what changed in the imperative, the body explains the reasoning, trade-offs, or context that the diff alone cannot convey. Footers, like the auto-generated Closes #123 and BREAKING CHANGE: lines, are the machine-readable trailers that tooling parses; the tool always separates subject, body, and footers with the blank lines the spec requires.

The diff analyzer

The "Analyze Diff" tab does lightweight pattern matching, not deep semantic analysis. Paste a git diff and it scans the text for tell-tale signs: filenames containing test or spec suggest test; .md, readme, or changelog suggest docs; added lines that introduce a function, class, const, or def suggest feat; touching package.json or requirements.txt suggests build; and .github, a Dockerfile, or .yml files suggest ci. It is a fast first guess to save you a click. Because it only inspects surface patterns, it cannot tell a feature from a refactor when both add functions — so treat its output as a starting suggestion and click "Apply Suggestion" only after confirming it matches your actual intent.

Tips and common mistakes

• Write the description in the imperative mood. "add login button", not "added" or "adds". The convention reads as "this commit will add the login button" — Git's own generated messages use the same tense.
• Keep the subject short. The tool caps the description at 72 characters and shows a live counter; long subjects get truncated in git log and on GitHub.
• One logical change per commit. If you need two types to describe a commit, it is probably two commits.
• Lowercase, no trailing period in the description — a small consistency rule that keeps changelogs tidy.
• Emoji are optional. They display fine on GitHub, GitLab, and Bitbucket, but if your team prefers plain text, leave the toggle off; the parseable structure does not depend on them.

Everything runs in your browser — nothing you type, including pasted diffs, is sent to a server.