What is the Conventional Commits specification?

Conventional Commits is a lightweight convention on top of commit messages. It provides a simple set of rules for creating an explicit commit history, making it easier to write automated tools. The format is: type(scope): description, followed by an optional body and one or more optional footers.

When should I use feat vs fix?

Use feat for any commit that introduces a new feature visible to the user or API consumer. Use fix for commits that patch a bug. Both types correlate directly to semantic versioning: feat bumps the MINOR version; fix bumps the PATCH version; a BREAKING CHANGE in either bumps the MAJOR version.

How do I mark a breaking change?

Check the "Breaking Change" checkbox in the builder and describe what breaks in the footer text box. This adds a BREAKING CHANGE: ... footer to your commit message, which signals tools like semantic-release to cut a new major version. You can also add an exclamation mark after the type/scope (e.g. feat!:) — the builder handles this automatically when the checkbox is checked.

What is the 72-character limit for the subject line?

Git and most forges (GitHub, GitLab, Bitbucket) truncate or wrap commit subjects at around 72 characters. Keeping your short description within this limit ensures the full subject is visible in git log --oneline and pull-request title previews without wrapping.

What does the scope field mean?

The scope is an optional noun in parentheses after the type that describes the section of the codebase the commit affects — for example feat(auth):, fix(api):, or docs(readme):. Use whatever noun is most meaningful to your project. Omit it when the change is global or cross-cutting.

Which types are supported?

The builder supports all standard types defined in the Conventional Commits and Angular conventions: feat, fix, docs, style, refactor, perf, test, build, ci, chore, and revert.

Conventional Commit Builder

Name: Conventional Commit Builder
Availability: InStock
Author: Nham Vu

Fill in commit type, optional scope, short description, and optional body/footers to instantly generate a spec-compliant Conventional Commits message you can copy with one click.

Commit Type & Scope

Type *

Scope (optional)

Short Description * 0 / 72

Use the imperative mood: "add feature" not "added feature". Keep under 72 characters.

Body (optional)

Footers

Breaking Change (bumps MAJOR version)

Issue Reference (optional)

Closes #

Preview

Select a type and add a description to see your commit message here.

Type	When to use
feat	Introduces a new user-facing feature (bumps MINOR)
fix	Patches a bug in the existing code (bumps PATCH)
docs	Documentation changes only — no code
style	Formatting, whitespace, missing semicolons (no logic change)
refactor	Code restructured with no feature addition or bug fix
perf	Change that improves performance
test	Adding or correcting tests
build	Build system, tooling, or dependency changes
ci	CI/CD configuration file or script changes
chore	Routine maintenance tasks not modifying production code
revert	Reverts a previous commit

Summary

Fill in commit type, optional scope, short description, and optional body/footers to instantly generate a spec-compliant Conventional Commits message you can copy with one click.

How it works

Select a commit type such as feat, fix, docs, or chore from the dropdown.
Optionally enter a scope — the module or area your change affects, e.g. auth or api.
Write a short description (imperative mood, max 72 chars recommended). The character counter updates live.
Optionally add a longer body to explain the motivation or context for the change.
If this is a breaking change, check the checkbox and describe what breaks in the footer field.
Optionally add a Closes / Fixes issue reference such as 123. Click Copy to copy the full message.

Use cases

Generating spec-compliant commit messages without memorizing the format
Onboarding developers who are new to Conventional Commits
Producing messages that trigger semantic-release or release-please automated versioning
Ensuring every commit has a machine-readable type for changelogs and CHANGELOG.md generation
Double-checking that a breaking change footer is correctly formatted before pushing
Creating commit templates for code-review checklists
Teaching the Conventional Commits specification in workshops or documentation
Quickly switching between types and scopes when working across multiple repositories

Frequently Asked Questions

Last updated: 2026-06-09 · Reviewed by Nham Vu