Conventional Commits in CONTRIBUTING.md

Adopting Conventional Commits

The Conventional Commits specification provides a lightweight convention for commit messages. It works well with semantic versioning and enables automated changelog generation.

The Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Common Types

Type	Description	Version Bump
feat	A new feature	Minor
fix	A bug fix	Patch
docs	Documentation changes	None
style	Formatting, missing semicolons	None
refactor	Code change that neither fixes nor adds	None
perf	Performance improvement	Patch
test	Adding or fixing tests	None
build	Build system or dependency changes	None
ci	CI configuration changes	None
chore	Other changes (e.g. .gitignore)	None

Scopes

Scopes narrow the area of the codebase affected:

feat(auth): add Google OAuth login
fix(api): handle timeout in fetch wrapper
docs(readme): update badge URLs

Breaking Changes

Use ! after the type/scope or a BREAKING CHANGE: footer:

feat(api)!: change response format to JSON:API

BREAKING CHANGE: The API response structure has changed.
Previous: { data: [...] }
New: { data: [...], meta: {...}, links: {...} }

Enforcement Tools

• commitlint -- Lint commit messages against the convention
• husky -- Git hooks to run commitlint on commit
• semantic-release -- Automated versioning and changelog based on commits
• standard-version -- Conventional changelog generation

Adding to CONTRIBUTING.md

Include the format, a table of types, 3-4 real examples from your project, and links to the tools you use for enforcement. This is more useful than linking to the spec alone.