Git Commit
Overview
Create clean, technical git commit messages in logical units. Analyze changes and group related modifications into separate commits.
Process
- •Check current branch with
git branch --show-current - •If on main/master: Create a feature branch (e.g.,
feat/<description>orfix/<description>) and switch to it, unless user explicitly requested committing to main - •Run
git statusandgit diffto analyze all changes - •Apply grouping algorithm to identify commit units
- •For each unit:
- •Stage only files for that unit
- •Draft succinct message (1-2 sentences max)
- •Create commit
- •Verify all changes are committed
Grouping Algorithm
- •Categorize each file by type (priority order: Fix > Feature > Refactor > Test > Doc > Config)
- •Build dependency graph (types before code, implementation before tests, refactors before fixes)
- •Merge units if: same directory AND same type AND <5 files total
- •Keep separate if: different types OR cross-module changes OR >4 files in group
- •Order commits: dependencies first, then independents, docs last
Change types:
- •Fix: Bug fixes addressing specific issues
- •Feature: New functionality in related files
- •Refactor: Code restructuring without behavior changes
- •Test: Test additions/modifications (commit with implementation if coupled)
- •Doc: Documentation updates
- •Config: Build config, dependencies, tooling
- •Types: Type definition changes (commit before code using them)
Coupling boundaries:
- •Tightly coupled (one commit): Type changes + code using them, renames affecting imports, implementation + its tests if <3 files
- •Independent (separate commits): Different modules, unrelated bug fixes, separate features, docs
Examples:
code
✅ Good grouping: Commit 1: Add null check to user validation (src/validation/user.ts) Commit 2: Update UserForm to use new validation (src/forms/UserForm.tsx, src/forms/UserForm.test.ts) Commit 3: Document validation rules (docs/api/validation.md) ❌ Bad grouping: Commit 1: Update validation and fix tests and add docs (mixes 3 types, unclear scope)
Circular dependencies: If fix A requires refactor B, create minimal commits preserving buildability: refactor first, then fix.
Message Guidelines
Focus on WHAT changed in the code:
- •"Add null checks to user validation"
- •"Extract database logic into separate module"
- •"Fix memory leak in event handler cleanup"
Avoid progress/milestone language:
- •❌ "Implement user authentication feature"
- •❌ "Continue work on API endpoints"
- •❌ "Add tests and improve code quality"
Edge Cases
Single logical unit: All changes tightly coupled → one commit
Mixed changes in one file: Use git add -p to stage hunks separately
Too many units (>6): Present grouping plan, ask user to confirm or merge
Important
- •Never commit directly to main/master unless the user explicitly requests it
- •Never include "Co-Authored-By: Claude" or "Generated with Claude Code"
- •No heredoc format with attribution footers
- •Describe technical change, not project progress
- •Default to multiple small commits over one large commit
- •Ensure every file is staged exactly once