​

Git Commit with Conventional Commits

​

Overview

​

Conventional Commit Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

​

Commit Types

​

Breaking Changes

# Exclamation mark after type/scope
feat!: remove deprecated endpoint

# BREAKING CHANGE footer
feat: allow config to extend other configs

BREAKING CHANGE: `extends` key behavior changed

​

Workflow

​

1. Analyze Diff

# If files are staged, use staged diff
git diff --staged

# If nothing staged, use working tree diff
git diff

# Also check status
git status --porcelain

​

2. Stage Files (if needed)

# Stage specific files
git add path/to/file1 path/to/file2

# Stage by pattern
git add *.test.*
git add src/components/*

# Interactive staging
git add -p

​

3. Generate Commit Message

• Type: What kind of change is this?
• Scope: What area/module is affected?
• Description: One-line summary of what changed (present tense, imperative mood, <72 chars)

​

4. Execute Commit

# Single line
git commit -m "<type>[scope]: <description>"

# Multi-line with body/footer
git commit -m "$(cat <<'EOF'
<type>[scope]: <description>

<optional body>

<optional footer>
EOF
)"

​

Best Practices

• One logical change per commit
• Present tense: “add” not “added”
• Imperative mood: “fix bug” not “fixes bug”
• Reference issues: Closes #123, Refs #456
• Keep description under 72 characters

​

Git Safety Protocol

• NEVER update git config
• NEVER run destructive commands (—force, hard reset) without explicit request
• NEVER skip hooks (—no-verify) unless user asks
• NEVER force push to main/master
• If commit fails due to hooks, fix and create NEW commit (don’t amend)