Git Commits

Name: Git Commits
Author: daleseo

daleseo/git-skills

11 installs
1 repo stars
Updated January 26, 2026
daleseo/git-skills

Teaches high-quality Git commits: Conventional Commits messages, atomic commits, staging strategies, and when to amend versus create new commits.

About

Explains Conventional Commits format, atomic-commit granularity, and smart staging for a meaningful history. Developers use it to generate clean, well-structured commit messages.

Conventional Commits type/scope/subject structure
Atomic commits and selective staging

Git Commits by the numbers

11 all-time installs (skills.sh)
Ranked #426 of 733 Git & Pull Requests skills by installs in the Skillselion catalog
Data as of Jul 29, 2026 (Skillselion catalog sync)

npx skills add https://github.com/daleseo/git-skills --skill git-commits

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/daleseo/git-skills/git-commits.svg)](https://skillselion.com/skills/daleseo/git-skills/git-commits)

Installs	11
repo stars	★ 1
Last updated	January 26, 2026
Repository	daleseo/git-skills ↗

What it does

Teaches high-quality Git commits: Conventional Commits messages, atomic commits, staging strategies, and when to amend versus create new commits.

Files

SKILL.mdMarkdownGitHub ↗

Git Commit Best Practices

Purpose: This skill teaches AI agents to create high-quality commits with clear messages, proper granularity, and effective use of the staging area.

Core Principles

1. Atomic Commits - One logical change per commit 2. Clear Messages - Follow Conventional Commits format 3. Meaningful History - Each commit tells a story 4. Smart Staging - Stage only what belongs together

Commit Message Format

Conventional Commits Structure

<type>(<scope>): <subject>

<body>

<footer>

Type Categories

# ✓ CORRECT: Use these standard types
feat:     # New feature for the user
fix:      # Bug fix
docs:     # Documentation changes
style:    # Formatting, missing semicolons, etc. (no code change)
refactor: # Code change that neither fixes a bug nor adds a feature
perf:     # Performance improvement
test:     # Adding or updating tests
chore:    # Maintenance tasks, dependencies, config

# Examples:
feat(auth): add password reset functionality
fix(api): handle null response in user endpoint
docs(readme): update installation instructions
refactor(parser): simplify token extraction logic

Subject Line Guidelines

# ✓ GOOD: Clear, concise, imperative mood
feat(auth): add OAuth2 login support
fix(cart): prevent duplicate items
docs(api): document rate limiting

# ✗ BAD: Vague, past tense, too long
feat(auth): added some authentication stuff
fix(cart): fixed a bug
docs(api): updated the documentation to include information about rate limiting

Rules:

Use imperative mood ("add" not "added" or "adds")
No period at the end
Keep under 50 characters
Capitalize first letter after type
Be specific about what changed

Body Guidelines

# ✓ GOOD: Explains WHY and context
feat(cache): add Redis caching layer

Improves API response time by 80% for frequently accessed data.
Uses Redis with 1-hour TTL for user profile and product catalog
endpoints. Falls back to database if Redis is unavailable.

Related to performance optimization initiative.

# ✗ BAD: Just repeats the subject
feat(cache): add Redis caching layer

Added Redis caching.

When to include body:

Why the change was needed
How it solves the problem
Any important implementation decisions
Side effects or limitations
Related issues or context

When to skip body:

Self-explanatory changes (e.g., "fix(typo): correct variable name")

Footer Guidelines

# Breaking changes
feat(api): change user endpoint response format

BREAKING CHANGE: User API now returns camelCase instead of snake_case.
Migration guide: https://docs.example.com/migration/v2

# Issue references
fix(auth): prevent token expiration race condition

Closes #123
Refs #456

# Co-authors
feat(search): implement full-text search

Co-authored-by: Jane Doe <jane@example.com>

Atomic Commits

What is an Atomic Commit?

Definition: One commit = one logical change

# ✓ GOOD: Atomic commits
git commit -m "feat(auth): add login endpoint"
git commit -m "feat(auth): add logout endpoint"
git commit -m "test(auth): add login tests"

# ✗ BAD: Non-atomic commit
git commit -m "feat(auth): add login, logout, password reset, and tests"

Benefits

1. Easy to review - Reviewer focuses on one change 2. Easy to revert - Undo specific change without affecting others 3. Easy to cherry-pick - Apply specific change to another branch 4. Clear history - Each commit has clear purpose

How to Create Atomic Commits

# ✓ CORRECT: Stage related changes only
# You made changes to auth.js, api.js, and tests.js

# Commit 1: Feature implementation
git add src/auth.js src/api.js
git commit -m "feat(auth): add token refresh mechanism"

# Commit 2: Tests
git add tests/auth.test.js
git commit -m "test(auth): add token refresh tests"

# ✗ WRONG: Stage everything together
git add .
git commit -m "feat(auth): add token refresh and tests"

Decision Tree: Should This Be One Commit?

Does this change have a single, clear purpose?
├─ YES → Can it be described in one sentence?
│  ├─ YES → One commit ✓
│  └─ NO  → Multiple commits
│
└─ NO → Multiple commits

Examples:
├─ "Add login validation" → One commit ✓
├─ "Add login and signup" → Two commits
└─ "Add login, fix bug, update docs" → Three commits

Staging Strategies

Strategy 1: Partial File Staging

# You changed multiple things in one file
# Only stage the lines related to current commit

git add -p src/app.js

# Interactive prompts:
# y - stage this hunk
# n - don't stage this hunk
# s - split into smaller hunks
# e - manually edit the hunk

# Then commit only staged changes
git commit -m "feat(app): add error handling"

# Stage and commit remaining changes separately
git add -p src/app.js
git commit -m "refactor(app): extract validation logic"

Strategy 2: Multiple Commits from Unstaged Work

# ✓ WORKFLOW: Create multiple atomic commits from current changes

# Check what changed
git status
git diff

# Commit 1: Feature A
git add src/feature-a.js src/utils.js
git commit -m "feat(feature-a): implement feature A"

# Commit 2: Feature B
git add src/feature-b.js
git commit -m "feat(feature-b): implement feature B"

# Commit 3: Tests
git add tests/
git commit -m "test: add tests for features A and B"

Strategy 3: Amend Last Commit

# Use case: You forgot to include a file in the last commit

# ✓ CORRECT: Amend if commit is NOT pushed yet
git add forgotten-file.js
git commit --amend --no-edit

# OR update the commit message too
git commit --amend -m "feat(auth): add login endpoint and middleware"

# ✗ WRONG: Amend if commit is already pushed
# This rewrites history and causes problems for collaborators

# If already pushed, create new commit instead:
git add forgotten-file.js
git commit -m "feat(auth): add missing middleware file"

Common Workflows

Workflow 1: Making a Feature Commit

# 1. Check current state
git status
git diff

# 2. Stage related changes only
git add src/feature.js src/api.js

# 3. Review what will be committed
git diff --staged

# 4. Commit with conventional format
git commit -m "feat(feature): add user profile customization

Allows users to customize avatar, bio, and theme preferences.
Settings are persisted to user preferences API endpoint.

Closes #234"

# 5. Verify commit
git log -1 --stat

Workflow 2: Making Multiple Atomic Commits

# You worked on multiple things, now need to commit separately

# 1. Check all changes
git status

# 2. First commit: Core feature
git add src/core.js
git commit -m "feat(core): add data validation layer"

# 3. Second commit: API integration
git add src/api.js
git commit -m "feat(api): integrate validation with endpoints"

# 4. Third commit: Tests
git add tests/
git commit -m "test(validation): add comprehensive validation tests"

# 5. Fourth commit: Documentation
git add docs/
git commit -m "docs(validation): document validation rules"

Workflow 3: Fixing a Bug

# ✓ GOOD: Clear bug fix commit

git add src/buggy-file.js
git commit -m "fix(cart): prevent duplicate items on double-click

Added debounce to 'Add to Cart' button and server-side duplicate
check. Prevents race condition when users click rapidly.

Fixes #567"

# Include:
# - What the bug was
# - How you fixed it
# - Issue reference

Workflow 4: Amending vs New Commit Decision

Did I already push this commit?
├─ NO → Safe to amend
│  └─> git commit --amend
│
└─ YES → Create new commit instead
   └─> git commit -m "fix: ..."

Is this a fixup for recent commit?
└─> Consider git commit --fixup=<sha>
    Then use git rebase -i --autosquash before pushing

Workflow 5: Refactoring Commits

# ✓ GOOD: Separate refactoring from behavior changes

# Commit 1: Pure refactor (no behavior change)
git add src/parser.js
git commit -m "refactor(parser): extract token validation to separate function

No behavior change. Makes code more testable and readable."

# Commit 2: Behavior change
git add src/parser.js
git commit -m "feat(parser): add support for nested tokens

Now supports tokens in format {{parent.child.value}}"

# Why separate?
# - Easy to verify refactor doesn't change behavior
# - Easy to revert feature without losing refactor
# - Clear history

Common Mistakes to Avoid

Mistake 1: Vague Commit Messages

# ✗ BAD: No context
git commit -m "update"
git commit -m "fix bug"
git commit -m "changes"
git commit -m "wip"

# ✓ GOOD: Clear and specific
git commit -m "feat(auth): add JWT token expiration check"
git commit -m "fix(api): handle null values in user profile endpoint"
git commit -m "refactor(parser): simplify regex patterns"
git commit -m "docs(readme): add Docker setup instructions"

Mistake 2: Mixing Unrelated Changes

# ✗ BAD: Multiple unrelated changes in one commit
git add .
git commit -m "feat: add login, fix cart bug, update docs"

# ✓ GOOD: Separate commits
git add src/auth.js
git commit -m "feat(auth): add OAuth login support"

git add src/cart.js
git commit -m "fix(cart): prevent negative quantities"

git add docs/
git commit -m "docs(api): update authentication endpoints"

Mistake 3: Committing Debug Code

# ✗ BAD: Leaving console.log, debugger statements
git add src/app.js  # Contains console.log debugging
git commit -m "feat(app): add feature"

# ✓ GOOD: Review before committing
git diff --staged  # Check for debug code
# Remove debug statements
git add src/app.js
git commit -m "feat(app): add feature"

Mistake 4: Too Large or Too Small Commits

# ✗ TOO LARGE: Entire feature in one commit
git commit -m "feat(auth): complete authentication system"
# 50 files changed, 2000+ lines

# ✗ TOO SMALL: Meaningless micro-commits
git commit -m "add semicolon"
git commit -m "fix typo"
git commit -m "add newline"

# ✓ GOOD: Right-sized atomic commits
git commit -m "feat(auth): add login endpoint"
git commit -m "feat(auth): add logout endpoint"
git commit -m "feat(auth): add token refresh mechanism"
git commit -m "test(auth): add authentication tests"

Mistake 5: Amending Pushed Commits

# ✗ DANGEROUS: Amending after push
git push origin feature-branch
# Oh, forgot a file!
git add forgotten.js
git commit --amend --no-edit
git push --force origin feature-branch  # ← Causes problems!

# ✓ SAFE: New commit instead
git push origin feature-branch
# Oh, forgot a file!
git add forgotten.js
git commit -m "feat(auth): add missing validation helper"
git push origin feature-branch

Commit Message Templates

Template for Features

feat(<scope>): <what you added>

<why this feature is needed>
<how it works (if not obvious)>
<any limitations or considerations>

Closes #<issue-number>

Template for Bug Fixes

fix(<scope>): <what you fixed>

<what was wrong>
<how you fixed it>
<why this approach>

Fixes #<issue-number>

Template for Refactoring

refactor(<scope>): <what you refactored>

No behavior change. <why refactor was needed>
<what improved (readability, performance, maintainability)>

Integration with AI Code Generation

When AI agents generate code that needs committing:

1. Analyze Changes Before Committing

# ✓ CORRECT: Check what changed
git status
git diff

# Determine:
# - Is this one logical change or multiple?
# - What type of change? (feat, fix, refactor, etc.)
# - What scope? (auth, api, ui, etc.)

2. Create Appropriate Commit Message

# ✓ GOOD: AI-generated message with context
git commit -m "feat(api): add rate limiting middleware

Implements token bucket algorithm with 100 requests/minute limit.
Returns 429 status with Retry-After header when limit exceeded.

Addresses security requirement from issue #789"

# ✗ BAD: Generic AI message
git commit -m "add rate limiting"

3. Split Large Changes

# If AI generated multiple files for different purposes:

# ✓ CORRECT: Separate commits
git add src/rate-limiter.js
git commit -m "feat(api): add rate limiting middleware"

git add tests/rate-limiter.test.js
git commit -m "test(api): add rate limiter tests"

git add docs/api.md
git commit -m "docs(api): document rate limiting"

# ✗ WRONG: One large commit
git add .
git commit -m "add rate limiting with tests and docs"

Quick Reference Checklist

Before every commit, ask:

[ ] Is this one logical change?
[ ] Did I stage only related files?
[ ] Is my commit message in Conventional Commits format?
[ ] Does the subject line clearly describe what changed?
[ ] Did I explain why (not just what) in the body?
[ ] Did I remove debug code and comments?
[ ] Is this commit NOT already pushed? (if planning to amend)
[ ] Would this be easy to review?
[ ] Would this be easy to revert if needed?

Advanced: Commit Message Psychology

Good commit messages answer:

1. What changed? (Subject line) 2. Why was it needed? (Body - business reason) 3. How does it work? (Body - technical approach) 4. What are the side effects? (Body - impacts)

# ✓ EXCELLENT: Answers all questions
feat(search): implement fuzzy search algorithm

Users frequently make typos in search queries, resulting in zero
results and poor experience. Implemented Levenshtein distance-based
fuzzy matching with tolerance of 2 characters.

Performance impact: ~50ms additional latency for searches, acceptable
given improved user experience. Results are cached for 5 minutes.

Closes #456

Summary

Key Principles: 1. One commit = one logical change (atomic commits) 2. Use Conventional Commits format (type, scope, clear subject) 3. Explain why, not just what (meaningful commit messages) 4. Stage strategically (use git add -p for partial staging) 5. Never amend pushed commits (creates new commit instead)

Quick Command Reference:

git add <file>                    # Stage specific file
git add -p <file>                 # Stage parts of file interactively
git diff --staged                 # Review what will be committed
git commit -m "type(scope): msg"  # Commit with message
git commit --amend --no-edit      # Amend last commit (if not pushed)
git log -1 --stat                 # Verify last commit

Remember: Commits are documentation of your project's history. Write them for humans who will read them 6 months from now.

Conventional Commits Deep Dive

Complete guide to the Conventional Commits specification and its practical application.

Specification

Based on conventionalcommits.org v1.0.0

Full Format

<type>[optional scope][optional !]: <description>

[optional body]

[optional footer(s)]

Type Categories (Extended)

Type	Purpose	When to Use	Example
feat	New feature	Adding new functionality for users	`feat(auth): add OAuth2 support`
fix	Bug fix	Fixing incorrect behavior	`fix(cart): prevent duplicate items`
docs	Documentation	Only documentation changes	`docs(readme): update installation steps`
style	Code style	Formatting, whitespace (no logic change)	`style(parser): fix indentation`
refactor	Code refactoring	Code change with no behavior change	`refactor(api): extract validation logic`
perf	Performance	Performance improvement	`perf(db): add index on user_id column`
test	Tests	Adding or updating tests	`test(auth): add login edge cases`
build	Build system	Build scripts, dependencies	`build(npm): upgrade to webpack 5`
ci	CI/CD	CI configuration changes	`ci(github): add automated testing workflow`
chore	Maintenance	Other changes (no src/test modification)	`chore(deps): update dependencies`
revert	Revert	Reverting previous commit	`revert: revert "feat(auth): add OAuth2"`

Scope Guidelines

Good scopes are specific but not too granular:

# ✓ GOOD: Clear, consistent scopes
feat(auth): ...        # Authentication module
fix(api): ...          # API layer
docs(contributing): ...# Specific doc file
perf(parser): ...      # Parser component

# ✗ TOO BROAD: Not helpful
feat(app): ...         # What part of app?
fix(code): ...         # Everything is code

# ✗ TOO NARROW: Too granular
feat(user-login-form): ...  # Just use "auth"
fix(cart-item-component): ...# Just use "cart"

Scope patterns by project type:

# Frontend projects
feat(ui): ...          # UI components
feat(store): ...       # State management
feat(router): ...      # Routing
fix(api-client): ...   # API integration

# Backend projects
feat(api): ...         # API endpoints
feat(db): ...          # Database
feat(auth): ...        # Authentication
fix(middleware): ...   # Middleware

# Full-stack projects
feat(client): ...      # Client-side
feat(server): ...      # Server-side
feat(shared): ...      # Shared code

Breaking Changes

Two ways to indicate breaking changes:

Method 1: Use `!` after type/scope

feat(api)!: change user endpoint response format

BREAKING CHANGE: User API now returns camelCase instead of snake_case.

Before:
{
  "user_name": "john",
  "created_at": "2024-01-01"
}

After:
{
  "userName": "john",
  "createdAt": "2024-01-01"
}

Migration: Update all API consumers to handle new format.

Method 2: Use `BREAKING CHANGE:` footer

refactor(auth): redesign token validation

BREAKING CHANGE: JWT tokens now require 'iss' claim.

All existing tokens will be invalid after this change.
Users will need to re-authenticate.

Body Guidelines

When to include a body:

# ✓ NEEDS BODY: Complex change requiring explanation
feat(cache): implement Redis caching layer

Previous implementation used in-memory cache which didn't scale
across multiple instances. Redis provides distributed caching with
configurable TTL and automatic eviction.

Configuration requires REDIS_URL environment variable.
Falls back to in-memory cache if Redis is unavailable.

# ✓ NO BODY NEEDED: Self-explanatory
fix(typo): correct variable name in auth module

# ✓ NO BODY NEEDED: Simple addition
docs(readme): add badge for build status

Body formatting:

# ✓ GOOD: Well-structured body
feat(search): implement full-text search

Motivation:
- Users reported difficulty finding products
- Current keyword search too restrictive

Implementation:
- PostgreSQL full-text search with tsvector
- Indexed on product name, description, tags
- Supports stemming and ranking

Performance:
- Search queries average 50ms
- Index size: ~100MB for 1M products

Limitations:
- English language only currently
- Requires PostgreSQL 12+

# ✗ BAD: Unstructured rambling
feat(search): implement full-text search

I added search because users wanted it and I used postgres
because it has fts and it's pretty fast and works well...

Footer Examples

# Issue references
Fixes #123
Closes #456, #789
Refs #234

# Breaking changes
BREAKING CHANGE: removed support for Node 14

# Co-authors
Co-authored-by: Jane Doe <jane@example.com>
Co-authored-by: John Smith <john@example.com>

# Multiple footers
feat(api): add GraphQL endpoint

BREAKING CHANGE: REST API endpoints deprecated
Closes #567
Refs #234, #345

Real-World Examples

Example 1: Simple Feature

feat(cart): add quantity selector

Allows users to change item quantity directly in cart view.
Updates total price in real-time using client-side calculation.

Closes #234

Why this is good:

Clear type (feat)
Specific scope (cart)
Concise subject (what was added)
Body explains behavior
Links to issue

Example 2: Bug Fix with Investigation

fix(auth): prevent token leakage in error responses

Error responses were including full JWT token in error.details field,
exposing tokens in client-side error logs and monitoring systems.

Root cause: Generic error handler was serializing entire request
object, which included Authorization header.

Solution: Sanitize error objects before serialization, removing
sensitive headers (Authorization, Cookie, X-API-Key).

Fixes #789 (security vulnerability)

Why this is good:

Explains what was wrong
Explains root cause
Explains solution
Security context clear

Example 3: Performance Optimization

perf(db): add composite index on user queries

Query performance for user search degraded as user table grew to 10M+
rows. Most queries filter by (status, created_at) combination.

Added composite index: idx_users_status_created_at

Results:
- Query time: 2500ms → 15ms (166x improvement)
- Index size: 450MB
- Index creation time: ~5 minutes

Trade-off: Slightly slower writes (negligible impact given read-heavy
workload). Recommend monitoring index bloat over time.

Why this is good:

Quantifies improvement
Explains trade-offs
Provides monitoring guidance

Example 4: Refactoring

refactor(parser): extract token validation into separate module

No behavior change. Moved token validation logic from parser.js
(800 lines) into dedicated validators/ directory.

Benefits:
- Improved testability (validators can be tested in isolation)
- Better code organization (SRP principle)
- Easier to add new token types

Files changed:
- src/parser.js (removed 200 lines)
- src/validators/token-validator.js (new, 150 lines)
- src/validators/index.js (new, 20 lines)

Why this is good:

Explicitly states "no behavior change"
Explains benefits
Shows file structure changes

Example 5: Documentation

docs(api): add examples for all authentication endpoints

Added request/response examples, error codes, and authentication
flow diagrams to API documentation.

Includes:
- Login endpoint examples (success, invalid credentials, rate limit)
- Logout endpoint examples
- Token refresh examples
- Common error scenarios

Based on feedback from issue #456 (docs unclear for new developers).

Example 6: Breaking Change

feat(api)!: redesign error response format

BREAKING CHANGE: Error responses now use RFC 7807 Problem Details.

Before:
{
  "error": "Invalid input",
  "code": 400
}

After:
{
  "type": "https://api.example.com/errors/invalid-input",
  "title": "Invalid Input",
  "status": 400,
  "detail": "The 'email' field must be a valid email address",
  "instance": "/users/123"
}

Migration:
1. Update all API clients to parse new error format
2. Error handling middleware needs updating
3. See migration guide: docs/migration/v3-errors.md

Rationale: Standardized format improves API consistency and provides
better debugging information for developers.

Closes #345

Anti-Patterns

Anti-Pattern 1: Vague Messages

# ✗ BAD
git commit -m "update"
git commit -m "fix"
git commit -m "changes"
git commit -m "wip"
git commit -m "stuff"

# ✓ GOOD
git commit -m "feat(auth): add password reset flow"
git commit -m "fix(cart): prevent duplicate items on double-click"
git commit -m "refactor(parser): simplify regex patterns"
git commit -m "docs(api): document rate limiting behavior"

Anti-Pattern 2: Mixing Multiple Types

# ✗ BAD: Multiple changes in one commit
git commit -m "feat(auth): add login, fix logout bug, update docs"

# ✓ GOOD: Separate commits
git commit -m "feat(auth): add OAuth login support"
git commit -m "fix(auth): prevent session leak on logout"
git commit -m "docs(auth): document OAuth configuration"

Anti-Pattern 3: Implementation Details in Subject

# ✗ BAD: Too much implementation detail
git commit -m "feat(db): add UserRepository class with findById, findAll, and save methods using TypeORM decorators"

# ✓ GOOD: What, not how
git commit -m "feat(db): add user repository layer"

# Details go in body:
feat(db): add user repository layer

Implements data access layer for user operations using TypeORM.
Provides findById, findAll, create, update, and delete methods.
Handles connection pooling and query optimization.

Anti-Pattern 4: Missing Context

# ✗ BAD: No context
git commit -m "fix(api): change timeout to 30s"

# ✓ GOOD: Explains why
git commit -m "fix(api): increase timeout to 30s for large exports

Previous 10s timeout caused failures for export operations with
>10k records. Analyzed metrics showing p95 export time is 25s.

Set to 30s to accommodate p99 while preventing indefinite hangs.
Added timeout monitoring to alert if p95 exceeds 20s.

Fixes #567"

Anti-Pattern 5: Jokes or Informal Language

# ✗ BAD: Unprofessional
git commit -m "fix(auth): oops, forgot to hash passwords lol"
git commit -m "feat(ui): made it look less ugly"
git commit -m "refactor(code): this code was garbage"

# ✓ GOOD: Professional
git commit -m "fix(auth): add password hashing before storage"
git commit -m "feat(ui): redesign dashboard layout"
git commit -m "refactor(parser): simplify control flow"

Commit Message Template

Create .gitmessage template:

# ~/.gitmessage
# <type>(<scope>): <subject>
#
# <body>
#
# <footer>

# Type: feat, fix, docs, style, refactor, perf, test, build, ci, chore, revert
# Scope: Component/module affected (optional)
# Subject: Imperative, no period, max 50 chars
#
# Body: Explain what and why (not how). Wrap at 72 chars.
#
# Footer: Issue references, breaking changes
#   Fixes #123
#   BREAKING CHANGE: description

Configure Git to use it:

git config --global commit.template ~/.gitmessage

Tools and Validation

Commitlint Configuration

// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'feat',
        'fix',
        'docs',
        'style',
        'refactor',
        'perf',
        'test',
        'build',
        'ci',
        'chore',
        'revert',
      ],
    ],
    'subject-case': [2, 'never', ['start-case', 'pascal-case', 'upper-case']],
    'subject-max-length': [2, 'always', 50],
    'body-max-line-length': [2, 'always', 72],
  },
};

Git Hooks for Validation

# .git/hooks/commit-msg
#!/bin/sh

# Validate commit message format
commit_msg=$(cat "$1")

# Check for conventional commits format
if ! echo "$commit_msg" | grep -qE '^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert)(\(.+\))?: .+'; then
    echo "Error: Commit message must follow Conventional Commits format"
    echo "Example: feat(auth): add login endpoint"
    exit 1
fi

# Check subject line length
subject=$(echo "$commit_msg" | head -n1)
if [ ${#subject} -gt 72 ]; then
    echo "Error: Subject line too long (max 72 characters)"
    exit 1
fi

Changelog Generation

Conventional commits enable automatic changelog generation:

# Using standard-version
npx standard-version

# Generates CHANGELOG.md:
## [2.1.0] - 2024-01-15

### Features
- **auth**: add OAuth2 support (#234)
- **api**: add rate limiting middleware (#345)

### Bug Fixes
- **cart**: prevent duplicate items (#456)
- **db**: fix connection pool leak (#567)

### BREAKING CHANGES
- **api**: error response format changed to RFC 7807

Summary

Conventional Commits provides: 1. ✅ Standardized commit history 2. ✅ Automatic changelog generation 3. ✅ Easier code review 4. ✅ Better project navigation 5. ✅ Semantic versioning automation

Key Rules:

Use standard types (feat, fix, docs, etc.)
Keep subject line under 50 characters
Use imperative mood ("add" not "added")
Explain why in the body
Reference issues in footer
Mark breaking changes with ! or BREAKING CHANGE:

Related skills

Caveman CommitGenerate terse, Conventional Commits messages that preserve intent without fluff or AI attribution.272k94k

Resolving Merge ConflictsQuickly understand, resolve, and commit merge conflicts without losing work or breaking their flow.183k193k

Git Guardrails Claude CodePrevent Claude Code from accidentally running destructive git commands like force push, hard reset, or clean.175k193k

Using Git WorktreesGuarantee every new feature or implementation task runs inside a clean, isolated workspace without polluting the main branch or current working directory.149k263k

Git CommitGenerate accurate conventional commit messages and intelligently stage files directly from natural language requests.40.6k37.2k

Resolve Merge ConflictsQuickly understand and resolve Git merge conflicts without losing context or breaking changes.16.5k148

Git & Pull Requestsgit

About

Git Commits by the numbers

Add your badge

What it does

Files

Git Commit Best Practices

Core Principles

Commit Message Format

Conventional Commits Structure

Type Categories

Subject Line Guidelines

Body Guidelines

Footer Guidelines

Atomic Commits

What is an Atomic Commit?

Benefits

How to Create Atomic Commits

Decision Tree: Should This Be One Commit?

Staging Strategies

Strategy 1: Partial File Staging

Strategy 2: Multiple Commits from Unstaged Work

Strategy 3: Amend Last Commit

Common Workflows

Workflow 1: Making a Feature Commit

Workflow 2: Making Multiple Atomic Commits

Workflow 3: Fixing a Bug

Workflow 4: Amending vs New Commit Decision

Workflow 5: Refactoring Commits

Common Mistakes to Avoid

Mistake 1: Vague Commit Messages

Mistake 2: Mixing Unrelated Changes

Mistake 3: Committing Debug Code

Mistake 4: Too Large or Too Small Commits

Mistake 5: Amending Pushed Commits

Commit Message Templates

Template for Features

Template for Bug Fixes

Template for Refactoring

Integration with AI Code Generation

1. Analyze Changes Before Committing

2. Create Appropriate Commit Message

3. Split Large Changes

Quick Reference Checklist

Advanced: Commit Message Psychology

Summary

Conventional Commits Deep Dive

Specification

Full Format

Type Categories (Extended)

Scope Guidelines

Breaking Changes

Method 1: Use ! after type/scope

Method 2: Use BREAKING CHANGE: footer

Body Guidelines

Footer Examples

Real-World Examples

Example 1: Simple Feature

Example 2: Bug Fix with Investigation

Example 3: Performance Optimization

Example 4: Refactoring

Example 5: Documentation

Example 6: Breaking Change

Anti-Patterns

Anti-Pattern 1: Vague Messages

Anti-Pattern 2: Mixing Multiple Types

Anti-Pattern 3: Implementation Details in Subject

Anti-Pattern 4: Missing Context

Anti-Pattern 5: Jokes or Informal Language

Commit Message Template

Tools and Validation

Commitlint Configuration

Git Hooks for Validation

Changelog Generation

Summary

Related skills

This week in AI coding

Method 1: Use `!` after type/scope

Method 2: Use `BREAKING CHANGE:` footer