Git Commit
Rules
- Never add
Co-Authored-Bylines to commit messages - Never mention Claude, AI, agent, copilot, or any automated tooling
- Never commit two unrelated changes together. Commits should be atomic.
- Commits must look like they were written by a human developer
Format
type(scope): subject
body (optional)
- subject: lowercase, imperative mood, no period, max 72 chars
- body: wrap at 72 chars, explain why not what, separated by blank line
Types
| Type | Use for |
|---|---|
feat | New feature |
fix | Bug fix |
refactor | Code change that neither fixes nor adds |
docs | Documentation only |
style | Formatting, semicolons, no code change |
test | Adding or updating tests |
chore | Build, tooling, deps, no production code |
perf | Performance improvement |
ci | CI/CD configuration |
Scope
Derive the scope from the primary area of change:
- Module or package name (
auth,api,db) - Feature area (
login,checkout,search) - Layer (
ui,server,cli)
Omit scope only when the change is truly project-wide.
Workflow
- Run
git statusandgit diff --staged(orgit diffif nothing staged) - Identify the primary change type and scope
- Write the commit message
- Stage relevant files by name (avoid
git add .orgit add -A) - Commit using a HEREDOC:
git commit -m "$(cat <<'EOF'
type(scope): subject
optional body
EOF
)"
Important Guideline
If a commit has the word end it means it is not atomic. Break into more than 1 to make them isolated.
Examples
feat(auth): add password reset flow
Allow users to reset their password via email link.
Tokens expire after 30 minutes.
fix(api): handle null response from payment gateway
refactor(db): extract query builder into separate module
chore(deps): upgrade react to v19