conventional-commit

Conventional Commit

Write commit messages that follow the Conventional Commits 1.0.0 spec. A compliant message drives changelog generation and semantic versioning.

Format

<type>(<optional scope>): <subject>

<optional body>

<optional footer(s)>

Allowed types

Type	Use for
feat	A new feature (triggers a MINOR bump)
fix	A bug fix (triggers a PATCH bump)
docs	Documentation only
refactor	Code change that neither fixes a bug nor adds a feature
test	Adding or correcting tests
chore	Maintenance that doesn't touch src or tests (e.g. tooling)
build	Changes to the build system or dependencies
ci	Changes to CI configuration or scripts
perf	A change that improves performance

Rules

• Subject: imperative mood ("add", not "added"/"adds"), no trailing period, ≤ 50 characters.
• Scope (optional): a noun in parentheses naming the area touched, e.g. feat(auth):.
• Body (optional): explain what and why, not how. Wrap lines at 72 characters. Separate from the subject with one blank line.
• Breaking changes: add a BREAKING CHANGE: footer describing the break (triggers a MAJOR bump). You may also append ! after the type/scope, e.g. feat(api)!:.
• Issue references: put them in the footer, e.g. Refs: #123 or Closes: #123.

Examples

✅ Good

feat(auth): add SSO login via SAML

Lets enterprise users authenticate against their own IdP. The
callback validates the SAML assertion signature before issuing
a session.

Closes: #482

fix(api): reject negative page sizes in list endpoint

refactor(billing)!: drop deprecated v1 invoice fields

BREAKING CHANGE: the `legacy_total` field is removed from the
invoice response. Clients must read `total` instead.

❌ Bad

Fixed the bug          # no type, past tense, vague

feat: Added a really long subject line that keeps going well past fifty characters
                       # past tense, capitalized after type, too long

update stuff           # no type, not imperative, meaningless subject