A new feature
Component or area affected
Imperative mood, lowercase, no period
0 / 72Issue refs, breaking change notes
Your commit message
Fill in the fields to generate a commit message// build structured commit messages from type, scope & summary
Build structured Git commit messages from type, scope, and summary fields. Generate conventional commits with breaking change flags and multi-line bodies instantly.
A new feature
Component or area affected
Imperative mood, lowercase, no period
0 / 72Issue refs, breaking change notes
Your commit message
Fill in the fields to generate a commit messageSelect the commit type that best describes your change — feat, fix, docs, etc.
Add an optional scope, write your summary, and optionally add a body and footer.
Click Copy or Copy as git command to use the message directly in your terminal.
The Conventional Commits specification is a lightweight convention on top of commit messages. It provides a set of rules for creating an explicit commit history that makes it easy to write automated tools on top of, such as semantic versioning and changelog generation.
Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. It defines a simple set of rules for creating an explicit commit history, making it easier to write automated tools like changelog generators and semantic versioning scripts on top of your Git history.
The scope is an optional field that provides additional context about which part of the codebase was changed. Common examples include component names (button, modal), modules (auth, payments), or architectural layers (api, ui, db). It appears in parentheses after the type: feat(auth): add OAuth support.
Mark a commit as a breaking change when it introduces a change that is incompatible with the previous API or behavior. This triggers a major version bump in semantic versioning. You can indicate breaking changes by adding a ! after the type (which this tool does automatically) or by adding a BREAKING CHANGE footer.
feat is for new features that add value to the end-user. chore is for maintenance tasks that don't affect the production code or user-facing behavior, like updating dependencies, configuring build tools, or reorganizing project structure. The distinction matters for changelog generation — feat and fix typically appear in changelogs while chore does not.
The conventional commits specification doesn't mandate a maximum length, but many tools and git hosting services display up to 72 characters before truncating. This tool warns you when the subject line exceeds 72 characters. Keeping it shorter (around 50 characters) is ideal for clean git log output.
Yes. The body field supports multi-line text, and this tool generates the proper blank-line separation between the subject, body, and footer that the conventional commits specification requires. When copying as a git commit -m command, the body is included with proper line breaks.
The footer is used for referencing GitHub issues (Closes #42, Fixes #17), adding co-authors (Co-authored-by: Name <email>), or noting breaking changes in full detail (BREAKING CHANGE: the `options` argument is now required). Multiple footers can be separated by newlines.
Tools like semantic-release and standard-version parse conventional commit messages to automatically determine the next version number. fix triggers a patch release, feat triggers a minor release, and a breaking change (! or BREAKING CHANGE footer) triggers a major release. Using this generator ensures your commits are compatible with these tools.
A conventional commit generator is a tool that helps developers write structured, machine-readable Git commit messages following the Conventional Commits specification. Instead of writing freeform commit messages that vary in style and informativeness, conventional commits follow a strict format that encodes the type of change, the area affected, and a clear description — all in the first line of the message.
This generator takes the guesswork out of the format. You select your commit type, optionally provide a scope and body, and the tool assembles the message correctly — ready to paste into your terminal or copy as a complete git commit -m command.
💡 Looking for premium web development assets? MonsterONE offers unlimited downloads of templates, UI kits, and developer assets — worth checking out for your next project.
A conventional commit message follows this structure:
<type>[optional scope][optional !]: <description>
[optional body]
[optional footer(s)]The type is the most critical field. It tells both humans and automated tools what category of change was made. The most commonly used types are:
Adopting the conventional commits standard brings tangible benefits to development teams of all sizes:
Tools like conventional-changelog, semantic-release, and release-it parse your commit history and automatically generate structured changelogs. A feat commit becomes a "Features" entry, a fix becomes a "Bug Fixes" entry, and so on — without any manual curation. This saves hours of release preparation work and ensures nothing gets missed.
When combined with semantic versioning tools, conventional commits enable fully automated version bumping. The rules are straightforward: fix commits increment the patch version (1.0.0 → 1.0.1), feat commits increment the minor version (1.0.0 → 1.1.0), and any commit marked as a breaking change (with ! or a BREAKING CHANGE footer) increments the major version (1.0.0 → 2.0.0). This removes subjective judgment from versioning decisions.
Structured commit messages are easier to scan in git log, pull request reviews, and code archaeology sessions. When every commit starts with a type, reviewers instantly understand the nature of a change before reading the description. New team members can orient themselves in a codebase by filtering commits by type.
Conventional commits encourage developers to think about what they're committing before they commit it. The discipline of categorizing a change forces more atomic, purposeful commits — rather than the common "fixed stuff" or "various changes" messages that plague many codebases.
The scope is optional but highly recommended for larger projects. It narrows the context of the change to a specific component, module, or area of the codebase. There's no universal list of valid scopes — each project should define its own, often matching component names, package names, or architectural layers.
Examples of good scopes by project type:
auth, checkout, header, modal, formsusers, payments, db, middleware, routes@myapp/ui, @myapp/core, @myapp/cliapi-docs, getting-started, changelog! MarkerWhen a commit introduces a change that is incompatible with the previous public API or contract, it must be flagged as a breaking change. This generator adds an exclamation mark immediately after the type (or scope) when you enable the breaking change toggle:
feat!: remove support for Node 14
feat(api)!: change authentication endpoint response formatYou can also include a BREAKING CHANGE: footer to describe what broke and what the migration path looks like. Both approaches are recognized by semantic versioning automation tools and will trigger a major version bump.
The subject line (type + scope + description) is the most critical part, but the body and footer add valuable context for future readers.
A well-written body explains the why behind the change — the problem it solves, alternatives considered, and any caveats. It should be wrapped at 72 characters per line and separated from the subject by a blank line.
The footer is the place for structured metadata: issue references (Closes #42), co-author credits (Co-authored-by: Name <email>), and breaking change descriptions. Tools like GitHub automatically close linked issues when commits with these footers are merged.
For teams looking to enforce conventional commits consistently, several tools can help. Commitlint is a linter that runs in CI or as a Git hook to validate that every commit message follows the spec. Husky makes it easy to add Git hooks to a Node.js project. Commitizen provides an interactive CLI prompt similar to what this web tool offers.
For open-source projects and those using GitHub Actions, adding a conventional commits check to pull requests ensures that the entire team — including external contributors — writes commit messages that are compatible with automated tooling.