Conventional Commits

Format all commit messages according to the Conventional Commits specification. This enables automated changelog generation, semantic versioning, and better commit history.

Format Structure

CODEBLOCK0

Commit Types

Required Types

• - feat: - A new feature (correlates with MINOR in Semantic Versioning)
• fix: - A bug fix (correlates with PATCH in Semantic Versioning)

Common Additional Types

• - docs: - Documentation only changes
• style: - Code style changes (formatting, missing semicolons, etc.)
• refactor: - Code refactoring without bug fixes or new features
• perf: - Performance improvements
• test: - Adding or updating tests
• build: - Build system or external dependencies changes
• ci: - CI/CD configuration changes
• chore: - Other changes that don't modify src or test files
• revert: - Reverts a previous commit

Scope

An optional scope provides additional contextual information about the section of the codebase:

CODEBLOCK1

Description

• - Must immediately follow the colon and space after the type/scope
• Use imperative mood ("add feature" not "added feature" or "adds feature")
• Don't capitalize the first letter
• No period at the end
• Keep it concise (typically 50-72 characters)

Body

• - Optional longer description providing additional context
• Must begin one blank line after the description
• Can consist of multiple paragraphs
• Explain the "what" and "why" of the change, not the "how"

Breaking Changes

Breaking changes can be indicated in two ways:

1. Using ! in the type/scope

CODEBLOCK2

2. Using BREAKING CHANGE footer

CODEBLOCK3

3. Both methods

CODEBLOCK4

Examples

Simple feature

CODEBLOCK5

Feature with scope

CODEBLOCK6

Bug fix with body

CODEBLOCK7

Breaking change

CODEBLOCK8

Documentation update

CODEBLOCK9

Multi-paragraph body with footers

CODEBLOCK10

Guidelines

1. 1. Always use a type - Every commit must start with a type followed by a colon and space
2. Use imperative mood - Write as if completing the sentence "If applied, this commit will..."
3. Be specific - The description should clearly communicate what changed
4. Keep it focused - One logical change per commit
5. Use scopes when helpful - Scopes help categorize changes within a codebase
6. Document breaking changes - Always indicate breaking changes clearly

Semantic Versioning Correlation

• - fix: → PATCH version bump (1.0.0 → 1.0.1)
• feat: → MINOR version bump (1.0.0 → 1.1.0)
• BREAKING CHANGE → MAJOR version bump (1.0.0 → 2.0.0)

When to Use

Use this format for:

• - All git commits
• Commit message generation
• Pull request merge commits
• When the user asks about commit messages or git commits

Common Mistakes to Avoid

❌ Added new feature (past tense, capitalized)
✅ feat: add new feature (imperative, lowercase)

❌ fix: bug (too vague)
✅ INLINECODE17

❌ feat: add feature (redundant)
✅ INLINECODE19

❌ feat: Added OAuth support. (past tense, period)
✅ INLINECODE21