Conventional Commits Cheat Sheet
A quick reference for the Conventional Commits specification — types, scopes, breaking changes, footers, and how each maps to semantic versioning. Every example is copy-ready.
🛠️ Build messages interactively with our Conventional Commits Generator.
Commit Types
| Type | Description | SemVer |
|---|---|---|
feat | A new feature for the user | minor |
fix | A bug fix for the user | patch |
docs | Documentation-only changes | — |
style | Formatting, white-space, semicolons (no code meaning change) | — |
refactor | Code change that neither fixes a bug nor adds a feature | — |
perf | A code change that improves performance | patch |
test | Adding missing tests or correcting existing ones | — |
build | Changes to the build system or dependencies | — |
ci | Changes to CI configuration files and scripts | — |
chore | Other changes that don't modify src or test files | — |
revert | Reverts a previous commit | — |
The Anatomy of a Commit
Full structure
<type>[optional scope][!]: <description>
[optional body]
[optional footer(s)] The header (first line) is required. A blank line separates it from the body, and another blank line separates the body from the footers.
Simplest valid commit
docs: fix typo in README Just a type and a description is enough for a valid Conventional Commit.
Examples by Type
Feature with scope
feat(auth): add password reset flow A new feature scoped to the auth module — triggers a MINOR version bump.
Bug fix
fix(api): handle null response from /users endpoint A backwards-compatible bug fix — triggers a PATCH version bump.
Chore / maintenance
chore(deps): bump vite from 5.4.2 to 5.4.8 Routine maintenance such as dependency updates. No release on its own.
Performance improvement
perf(parser): cache compiled regex patterns A change that improves performance — counts as a PATCH bump.
Scopes
With a scope
feat(checkout): support Apple Pay A scope is a noun in parentheses describing the affected area of the codebase. Useful in monorepos and large apps.
Without a scope
feat: support Apple Pay Scopes are optional. Omit them for small projects or changes that span the whole codebase.
Breaking Changes
Shorthand with !
feat(api)!: remove deprecated v1 endpoints Add a ! before the colon to flag a breaking change. This alone triggers a MAJOR version bump.
With a BREAKING CHANGE footer
feat(api)!: change auth token format
BREAKING CHANGE: tokens are now JWTs. Clients must
re-authenticate; legacy opaque tokens are rejected. The footer explains what breaks and how to migrate. The footer alone (even without !) is enough to mark a major change.
Writing the Body
Explain the why
fix(cache): invalidate user cache on profile update
The profile page showed stale data because the cache
was never cleared after a mutation. We now bust the
relevant keys inside the update handler. Use the body to explain motivation and contrast with previous behavior — not how the code works (the diff shows that).
Footers
Reference issues
fix(ui): correct button alignment on mobile
Closes #142
Refs #98 Footers carry metadata. Issue references like Closes #142 can auto-close issues on GitHub/GitLab.
Co-authors and sign-off
feat(editor): add collaborative cursors
Reviewed-by: Jane Doe
Co-authored-by: Sam Lee <sam@example.com>
Signed-off-by: Alex Kim <alex@example.com> Common footer tokens include Reviewed-by, Co-authored-by, Signed-off-by, and Acked-by. Use a "token: value" format.
Reverting Commits
Revert a commit
revert: feat(auth): add password reset flow
This reverts commit 9fceb02. Use the revert type and reference the SHA of the reverted commit in the body.
Common Tooling
Lint commit messages with commitlint
npm install --save-dev @commitlint/{cli,config-conventional}
echo "export default { extends: ['@commitlint/config-conventional'] };" > commitlint.config.js commitlint enforces the convention in a Git hook so malformed messages are rejected.
Interactive prompts with Commitizen
npm install -g commitizen
git cz Commitizen walks you through type, scope, and description with a guided prompt.
Automated releases with semantic-release
npm install --save-dev semantic-release
npx semantic-release Reads your commit history to determine the next version, generate a changelog, and publish — fully automated.
Semantic Versioning Mapping
| Commit | Release | Example | Meaning |
|---|---|---|---|
fix: | PATCH | 1.2.3 → 1.2.4 | Backwards-compatible bug fix |
feat: | MINOR | 1.2.3 → 1.3.0 | Backwards-compatible new feature |
feat!: / BREAKING CHANGE: | MAJOR | 1.2.3 → 2.0.0 | Breaking, incompatible API change |
About the Conventional Commits Cheat Sheet
Conventional Commits is a lightweight convention layered on top of your commit messages. It provides a simple set of rules for creating an explicit commit history, which makes it easier to write automated tools on top of. The format pairs naturally with Semantic Versioning by describing the features, fixes, and breaking changes made in each commit.
This cheat sheet collects the entire specification in one scannable place: the message anatomy, every commit type, scopes, breaking-change notation, body and footer conventions, and the exact mapping from commit type to version bump — all with copy-ready examples.
How to Use the Conventional Commits Cheat Sheet
- 1. Find the commit type that matches your change in the table above.
- 2. Follow the anatomy section to structure the header, body, and footers correctly.
- 3. Copy a matching example and adapt the scope and description to your change.
- 4. For incompatible changes, apply the breaking change rules (a
!and/or aBREAKING CHANGE:footer). - 5. Add footers to link issues or credit collaborators.
- 6. Check the semantic-versioning table to know which release your commit triggers.
Common Use Cases
Automated changelogs
Generate release notes directly from commit history with tools like semantic-release or standard-version.
Predictable versioning
Let the commit type decide the next version number automatically — no manual bumping.
Team consistency
Give every contributor a shared, enforceable commit style across the repository.
Readable history
Make git log, blame, and bisect far easier to scan and reason about.