Commit Conventions

Commit Message Conventions

Writing clear and consistent commit messages is essential for maintaining an understandable and traceable code history. Follow the Conventional Commits format.

Commit Message Structure

<type>[scope]: <short description>

[optional body]

[optional footer]

Components

<type> (required) - The type of change:

• feat: New feature
• fix: Bug fix
• docs: Documentation changes
• style: Code formatting without functional changes
• refactor: Code improvements without new features
• test: Adding or updating tests
• chore: Maintenance tasks (dependency updates, config changes)
• perf: Performance improvements
• ci: CI/CD configuration changes
• build: Build system or dependency changes

[scope] (optional) - The component, module, or section affected:

• Examples: (auth), (api), (ui), (header), (footer)

<short description> (required) - Brief description of the change:

• Max 50-72 characters
• Use present tense
• Lowercase start (after type)
• No period at the end

[body] (optional) - Detailed explanation:

• Wrap at 72 characters
• Explain what and why, not how
• Separate from description with blank line

[footer] (optional) - Breaking changes or issue references:

• BREAKING CHANGE: for breaking changes
• Issue references: Closes #123, Fixes #456

Commit Message Rules

1. Concise and specific: Keep description under 72 characters
2. Present tense: Use "Add" not "Added", "Fix" not "Fixed"
3. No period: Don't end the description with a period
4. Imperative mood: Write as if giving a command
5. Clear scope: Use scope to indicate what part of the codebase changed

Examples

New Feature

feat(header): add dropdown menu to navbar

Bug Fix

fix(api): resolve error when fetching user data

Documentation

docs(readme): add installation instructions

Code Refactor

refactor(utils): restructure formatting logic

Tests

test(auth): add tests for password recovery

Maintenance

chore(dependencies): update axios to v1.3.0

Performance

perf(images): optimize image loading with lazy loading

Breaking Change

feat(api): change authentication endpoint structure

BREAKING CHANGE: The /auth endpoint now returns a different response structure.
Clients must update to handle the new format.

With Issue Reference

fix(login): prevent memory leak on logout

The logout function was not properly cleaning up event listeners,
causing a memory leak after repeated login/logout cycles.

Fixes #234

Multiple Scopes

feat(api, ui): add user profile avatar upload

Bad Examples (Don't Do This)

❌ Fixed bug - Too vague, missing type and scope ❌ feat: Added new feature. - Has period, past tense ❌ update readme - Missing type ❌ feat(API): Add Feature - Uppercase scope and description ❌ WIP commit - Not descriptive, use proper type

Good Examples (Do This)

✅ feat(auth): add two-factor authentication ✅ fix(cart): resolve total calculation error ✅ docs(api): update endpoint documentation ✅ refactor(user-service): simplify user validation logic ✅ test(checkout): add integration tests for payment flow

Commit Frequency

• Commit early and often
• Each commit should be a logical unit of work
• Commits should not break the build
• Group related changes together

When to Apply

Apply these conventions when:

• Making any git commit
• Creating pull requests
• Reviewing commit history
• Setting up git hooks
• Generating changelogs
• User asks about commit standards

Tools

Consider using these tools to enforce commit conventions:

• commitlint: Lint commit messages
• husky: Git hooks for validation
• commitizen: Interactive commit message builder
• standard-version: Automated versioning and changelog