What is the Conventional Commits specification?

Conventional Commits is a lightweight convention on top of commit messages providing an easy set of rules for creating an explicit commit history. It follows the structure: [optional scope]: , followed by an optional body and footers. This convention enables automated semantic versioning (SemVer) bumps and automated CHANGELOG generation via tools like semantic-release.

How do I mark a Breaking Change in Conventional Commits?

A breaking change can be denoted in two ways: by appending an exclamation mark '!' immediately before the colon in the commit header (e.g. feat(api)!: remove v1 endpoints) and/or by including a footer beginning with 'BREAKING CHANGE: '.

What is the difference between feat and fix in SemVer?

A commit of type 'feat' introduces a new feature and correlates to a SemVer MINOR release bump (e.g., 1.2.0 -> 1.3.0). A commit of type 'fix' patches a bug and correlates to a SemVer PATCH release bump (e.g., 1.2.0 -> 1.2.1). Any commit containing a BREAKING CHANGE triggers a MAJOR release bump (e.g., 1.2.0 -> 2.0.0).

Conventional Commits Generator & Git Message Linter

Build & Lint Conventional Commits

Generate standardized semantic commit messages for automated changelogs and release versioning. 1-click terminal command copy with real-time lint validation.

Dev Tools Explore Git GUI clients, cloud CI/CD pipelines, and automated release orchestration software.

Commit Header

Type (Semantic Intent)

Optional Scope

Presets:

Short Imperative Description 0 / 50 chars

✓ Good length under 50 characters

Breaking Change (SemVer MAJOR bump) Appends '!' to header and inserts 'BREAKING CHANGE:' footer note.

Optional Body & Issue References

Extended Body

Issue Reference

Co-Author

📄 Commit Message Preview

MINOR (v1.x.0)

💻 1-Click Terminal Command

Bash, Zsh, PowerShell

Conventional Commits Checklist

✓Imperative mood

✓Starts lowercase

✓No trailing period

✓Length ≤ 72 characters

Semantic Versioning Commit Matrix

Standard Conventional Commit types and their mapped SemVer release impacts.

Type	SemVer Impact	Purpose & Description	Example Header
feat	MINOR	A new feature introduced for the consumer or end user.	feat(cart): add one-click apple pay checkout
fix	PATCH	A bug fix in production application code.	fix(api): resolve null pointer on token expiration
ANY + !	MAJOR	Breaking change that alters API contracts or schemas.	feat(auth)!: replace legacy session cookie with JWT
perf	PATCH	A code change that noticeably improves execution performance.	perf(query): index user_id on transactions table
docs	NONE	Documentation, markdown guides, or docstring updates.	docs(readme): add docker-compose installation guide
refactor	NONE / PATCH	Restructuring code without altering external behavior.	refactor(parser): extract tokenize method into helper

Frequently Asked Questions

Why should I use Conventional Commits? ▾

Conventional Commits enable continuous delivery pipelines to automate versioning completely. Tools like Semantic Release, Changesets, and standard-version read your git log to automatically determine whether to bump patch, minor, or major SemVer, generate CHANGELOG.md files, and publish packages without manual human intervention.

Why should commit descriptions start with a lowercase letter and have no period? ▾

Commit headers serve as concise titles, not full sentences. Because the header begins with a prefix such as "feat(ui): ", writing a capitalized word immediately after the colon breaks grammatical flow. Omitting the trailing period preserves precious character width (adhering to the standard 50-72 character terminal limit).

How do Co-Authored-By footers work? ▾

GitHub, GitLab, and Bitbucket natively recognize git trailer lines in the format `Co-authored-by: Name <email@example.com>`. When included in the commit footer separated by a blank line, GitHub will attribute commit contributions to all specified co-authors on the repository commit graph.

GitFormat Pro