Conventional Commits

Conventional Commits

Overview

Conventional Commits is a specification for commit messages that provides an explicit structure for creating a clear commit history. It enables automated tools for generating changelogs, determining semantic version bumps, and communicating changes effectively.

Core Principle: Every commit message follows a structured format that clearly communicates the type and scope of changes.

Commit Message Structure

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Quick Reference

Commit Types

Standard Types

• `feat`: A new feature (correlates with MINOR in SemVer)
• `fix`: A bug fix (correlates with PATCH in SemVer)

Additional Types (Common)

• `build`: Changes to build system or dependencies
• `chore`: Maintenance tasks, no production code change
• `ci`: Changes to CI configuration
• `docs`: Documentation only changes
• `hotfix`: Emergency bug fix applied directly to production, bypassing normal development workflow (correlates with PATCH in SemVer)
• `perf`: Performance improvements
• `refactor`: Code refactoring without behavior change
• `style`: Code style changes (formatting, missing semicolons, etc.)
• `test`: Adding or updating tests

Breaking Changes

Breaking changes can be indicated in two ways:

1. In the type/scope prefix: Append ! before the colon

   feat!: remove deprecated API
   feat(api)!: change authentication method

2. In the footer: Use BREAKING CHANGE: token

   feat: add new authentication system

   BREAKING CHANGE: Old authentication tokens are no longer valid

Examples

Basic Feature Commit

feat: add user authentication endpoint

Implement JWT-based authentication with login and token validation

Feature with Scope

feat(auth): implement password reset flow

Add forgot password endpoint and email notification system

Bug Fix

fix(parser): correct array parsing with multiple spaces

Handle edge case where strings contained multiple consecutive spaces

Breaking Change (Prefix)

feat(api)!: remove deprecated v1 endpoints

BREAKING CHANGE: All v1 API endpoints have been removed. Migrate to v2.

Breaking Change (Footer)

feat: update database schema

BREAKING CHANGE: Environment variables now take precedence over config files

Documentation

docs: update API reference for authentication endpoints

Refactoring

refactor(auth): extract token validation to separate module

Improve code organization and testability

Performance

perf(queries): optimize database query for user lookup

Reduce query time from 500ms to 50ms by adding index

Hotfix

Security Hotfix

hotfix(auth): fix critical security vulnerability in token validation

Immediate fix for CVE-2024-XXXX. Patch token validation to prevent unauthorized access.

Database Hotfix

hotfix(db): fix connection pool exhaustion causing service outage

Emergency patch to increase pool size and add connection timeout. Applied directly to production to restore service.

Payment Hotfix

hotfix(payment): fix incorrect currency conversion in checkout

Critical bug causing incorrect charges. Immediate fix applied to prevent financial impact.

API Hotfix

hotfix(api): fix null pointer exception in user endpoint

Emergency fix for production crash. Bypassed normal deployment process.

Performance Hotfix

hotfix(cache): fix memory leak causing server crashes

Immediate fix for production instability. Applied hotfix to prevent service degradation.

Data Integrity Hotfix

hotfix(data): fix corrupted data migration affecting user accounts

Emergency fix applied directly to production database to prevent data loss.

Common Mistakes

❌ Missing Colon and Space

feat add authentication

✅ Correct:

feat: add authentication

❌ Uppercase Type

FEAT: add authentication

✅ Correct:

feat: add authentication

❌ Description Too Long

feat: add user authentication with JWT tokens, password hashing, session management, and email verification

✅ Correct:

feat(auth): implement JWT-based authentication

Add login endpoint, password hashing, session management, and email verification

❌ Using Wrong Type

fix: add new feature for user dashboard

✅ Correct:

feat: add user dashboard

❌ Breaking Change Not Indicated

feat(api): remove deprecated endpoints

✅ Correct:

feat(api)!: remove deprecated endpoints

BREAKING CHANGE: All v1 endpoints have been removed

❌ Scope Without Parentheses

feat auth: implement login

✅ Correct:

feat(auth): implement login

Workflow Guidelines

When Creating Commits

1. Determine the type: Is this a feature, fix, or other type?

• Use hotfix for emergency fixes applied directly to production, bypassing normal development workflow
• Use fix for regular bug fixes in normal development workflow

2. Identify scope (optional): Which part of the codebase is affected? 3. Check for breaking changes: Does this change break existing functionality? 4. Write concise description: Keep under 72 characters when possible 5. Add body if needed: Provide context, motivation, or details 6. Include footer if applicable: Add breaking changes, references, etc.

Description Best Practices

• Use imperative mood: "add feature" not "added feature" or "adds feature"
• Don't end with a period
• Keep it concise (50-72 characters ideal)
• Focus on what changed, not why (why goes in body)

Body Best Practices

• Separate from description with blank line
• Explain the "why" behind the change
• Provide context or background
• Reference related issues or PRs

Semantic Versioning Correlation

Validation Checklist

Before finalizing a commit message, verify:

• [ ] Type is lowercase and valid
• [ ] Colon and space follow type/scope
• [ ] Description is concise and imperative
• [ ] Breaking changes are properly indicated
• [ ] Body is separated by blank line (if present)
• [ ] Footer tokens use hyphens (e.g., BREAKING CHANGE, not BREAKING_CHANGE)
• [ ] Message doesn't exceed 120 characters in title (if team standard)

Special Cases

Revert Commits

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

Multiple Commits for One Feature

If a commit conforms to multiple types, split into separate commits when possible:

feat(auth): add login endpoint
test(auth): add login endpoint tests
docs(auth): update API documentation for login

Integration with Tools

Conventional Commits enables:

• Automatic changelog generation: Tools parse commit history
• Semantic versioning: Automated version bumps based on commit types
• Release notes: Extract features and fixes from commits
• Build triggers: Different build processes for different commit types

Additional Resources

• reference.md — Official spec, commit types, SemVer correlation, tooling — indexable
• Official spec: https://www.conventionalcommits.org/en/v1.0.0/

Specification Reference

This skill is based on the official Conventional Commits specification v1.0.0.

All rules, examples, and guidelines in this skill follow the official specification. For the complete specification, examples, and FAQ, refer to the official documentation.

License

Skill License - Free Use

This skill (the documentation, structure, and implementation) was created by Ender Puentes <Endev/> and is provided for free and open use. You are free to:

• ✅ Use this skill in any project, personal or commercial
• ✅ Modify the skill to fit your needs
• ✅ Distribute the skill to others
• ✅ Share modified versions of the skill
• ✅ Include this skill in your own skill collections

No restrictions apply - this skill is available for unrestricted use. Attribution is appreciated but not required.

Note: This skill documents and references the Conventional Commits specification, but the skill itself is an independent work created for team use.

---

Conventional Commits Specification

This skill documents the Conventional Commits specification, which is a separate work created by the Conventional Commits contributors.

The Conventional Commits specification is NOT owned by the skill author. The specification has its own license:

Creative Commons Attribution 3.0 Unported (CC BY 3.0)

For information about the Conventional Commits specification license, visit: https://creativecommons.org/licenses/by/3.0/

Specification Source: https://www.conventionalcommits.org/en/v1.0.0/

This skill simply documents and references the specification for educational and practical use. The skill author claims no ownership or rights over the Conventional Commits specification itself.

Skill Author

This skill was created by Ender Puentes <Endev/> - https://enderpuentes.com

The skill itself (as a documentation/implementation work) is released for free and unrestricted use. While attribution is appreciated, it is not required for using, modifying, or distributing this skill.

Conventional Commits — Reference & Official Documentation

This file complements the conventional-commits skill with official documentation links for indexing.

Official documentation (indexable)

• Specification v1.0.0: https://www.conventionalcommits.org/en/v1.0.0/
• FAQ: https://www.conventionalcommits.org/en/v1.0.0/#faq
• Examples: https://www.conventionalcommits.org/en/v1.0.0/#examples

Specification summary

• Format: <type>[optional scope]: <description>
• Footer: BREAKING CHANGE: or Token: value
• Breaking change indicator: ! after type/scope

Commit types (standard)

• feat: New feature (SemVer MINOR)
• fix: Bug fix (SemVer PATCH)

Commit types (common extensions)

• build, chore, ci, docs, hotfix, perf, refactor, style, test
• revert: Revert a previous commit

Semantic Versioning correlation

• fix / hotfix → PATCH (1.0.0 → 1.0.1)
• feat → MINOR (1.0.0 → 1.1.0)
• BREAKING CHANGE / ! → MAJOR (1.0.0 → 2.0.0)

Tooling (ecosystem)

• standard-version: https://github.com/conventional-changelog/standard-version
• semantic-release: https://github.com/semantic-release/semantic-release
• commitlint: https://commitlint.js.org/
• conventional-changelog: https://github.com/conventional-changelog/conventional-changelog
• husky + commitlint: Pre-commit validation

Footer tokens

• BREAKING CHANGE: Indicates breaking change (MAJOR bump)
• Refs: Reference to commits, issues, PRs
• Co-authored-by: https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors

Best practices (reminder)

• Imperative mood: "add" not "added" or "adds"
• Description ≤ 72 characters (or 120 per team)
• Scope in parentheses: feat(auth):
• Colon and space after type/scope: feat: