Conventional Commit Generator
Build git commit messages following the Conventional Commits 1.0 spec. Pick a type, add a scope, write a subject — the tool produces a correctly-formatted commit message that passes commitlint and drives semantic-release.
Fill in type + subject — the commit message will appear here.About Conventional Commit Generator
The Conventional Commits specification is a lightweight convention for structuring git commit messages: a type (feat, fix, docs, refactor, etc.), an optional scope in parentheses, a short imperative subject, an optional body, and optional footers for breaking changes and issue references. When your team follows this convention, tools like commitlint, semantic-release, and standard-version can automatically generate changelogs and calculate the next version number directly from your git history — no manual release notes, no manual version bumps. This generator produces correctly-formatted commit messages that pass every mainstream commitlint config on the first try.
The form guides you through the parts of a good commit: type selection with human-friendly descriptions (feat bumps MINOR, fix bumps PATCH, breaking changes bump MAJOR), a subject length warning at 72 characters, a body field for context, a breaking-change toggle that adds both the '!' marker and the BREAKING CHANGE footer semantic-release detects, and issue references that get formatted into the standard 'Refs: #123' footer. Copy the message directly or copy as a ready-to-run git commit command. Genuinely useful for teams adopting Conventional Commits for the first time, developers who prefer typed input to memorizing conventions, and code reviewers who want commit messages that read well six months later.
How to Use
Pick a commit type from the dropdown — feat and fix are the most common.
Optionally add a scope in parentheses (a component or module name like 'auth' or 'api').
Write a short, imperative-mood subject line — 'add password reset' beats 'added password reset'.
Add body paragraphs for context, motivation, or side effects. Skip if not needed.
Check 'Breaking change' if this commit introduces backward-incompatible changes — semantic-release will trigger a MAJOR version bump.
Reference related issues or PRs (comma-separated, with or without #).
Copy the generated message and paste it into your git commit -m command.
Frequently Asked Questions
What is the Conventional Commits specification?
A lightweight convention for structuring git commit messages: 'type(scope): subject' on the first line, optional body, optional footers. It works cleanly with tools like commitlint, semantic-release, and standard-version to generate changelogs and version numbers automatically from your git history.
Do I need Conventional Commits to use this generator?
No — the generator produces a well-structured commit message even if your team does not use the tooling. Even without semantic-release, structured commits make git log significantly easier to read and grep.
Which commit type should I use for updating dependencies?
'chore' for internal tooling and dev dependencies (linter, prettier, test frameworks). 'build' for build-system dependencies (webpack, vite, package.json prod deps that affect the build). 'fix' if the dependency update patches a bug in your app. 'feat' if the update unlocks a new feature.
How does the breaking-change flag work?
Adding '!' after the type (feat!, fix!) OR including a 'BREAKING CHANGE:' footer marks the commit as introducing backward-incompatible changes. semantic-release detects either signal and bumps the MAJOR version on the next release. This generator adds both — the '!' for humans, the footer for tooling.
Why should the subject line be under 72 characters?
Most git tools (git log --oneline, GitHub PR titles, terminal-based interfaces) truncate at 72 characters. Keep the subject punchy and put the details in the body. The tool warns you when the subject exceeds the recommended length.