conventional-commits

name	conventional-commits
description	Write commit messages following the Conventional Commits specification for use with release-notes-gen. Use when composing git commit messages, understanding commit types, or setting up commit message conventions. Triggers include "conventional commits", "commit format", "commit message", "feat fix chore", "how to write commits".

conventional-commits

Reference guide for the Conventional Commits specification used by release-notes-gen.

Format

type(scope): description

[optional body]

[optional footer]

Commit Types

Type	When to Use	Bump
feat	New user-facing feature	minor
fix	Bug fix	patch
perf	Performance improvement	patch
refactor	Code restructure, no behavior change	none
docs	Documentation only	none
style	Formatting, whitespace	none
test	Add or fix tests	none
build	Build system, dependencies	none
ci	CI/CD configuration	none
chore	Maintenance, tooling	none

Examples

Feature

feat(auth): add OAuth2 login support

Bug Fix

fix(ui): align button correctly on mobile Safari

Breaking Change (two forms)

Using ! after type:

feat!: remove support for Node 18

Using footer:

feat(api): change response format

BREAKING CHANGE: the `data` field is now an array instead of object.
Clients must update to handle the new format.

With Scope

fix(database): handle null value in user query
feat(cli): add --dry-run flag
docs(readme): add quickstart section

Without Scope

fix: prevent crash on empty input
chore: update dependencies

How rng Uses Commit Messages

Version bump calculation - rng scans all commits since the last tag and computes the highest applicable bump: breaking=major, feat=minor, fix/perf=patch.

Section grouping - Commits grouped by type into sections in the release notes. feat commits go under "Features", fix under "Bug Fixes", etc.

Hidden types - chore, docs, style, test, build, ci, refactor are hidden by default (not shown in release notes unless --include-all is used). Customize in .rng.json.

Non-conforming commits - Commits that do not follow the format are grouped as type other and hidden by default.

Tips

• Use scope for module/area: fix(auth):, feat(api):, docs(readme):
• Keep description short (under 72 chars) and in imperative mood: "add" not "added"
• Use body for longer explanation when needed
• Use BREAKING CHANGE: footer when the breaking change needs explanation beyond the description line