Git Commit

Create well-scoped, reviewable commits with Conventional Commit messages.

Conventional Commit Format

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Breaking changes: feat!: summary or BREAKING CHANGE: footer.

Workflow

1. Inspect working tree

git status
git diff --stat
git diff

2. Decide commit boundaries

Split when changes contain unrelated concerns:

• feature vs refactor
• backend vs frontend
• formatting vs logic
• tests vs production code
• dependency bumps vs behavior changes

Default to multiple small commits when in doubt.

3. Stage only what belongs in the next commit

git add path/to/file
git add -p            # patch staging for mixed changes in one file
git restore --staged -p  # unstage a hunk

4. Sanity check staged changes

git diff --cached

Verify:

• No secrets or tokens
• No debug logging (console.log, debugger, etc.)
• No unrelated formatting churn

5. Describe the commit in 1-2 sentences

Answer: “What changed?” + “Why?”

If you cannot describe it cleanly, the commit is too big or mixed — go back to step 2.

6. Write the commit message

git commit -m "$(cat <<'EOF'
<type>[scope]: <description>

<body: what/why>

<footer>
EOF
)"

• Description: imperative mood, present tense, <72 chars
• Body: what and why, not implementation diary
• Footer: Closes #123, Refs #456, BREAKING CHANGE: if needed

7. Verify

Run the repo’s fastest meaningful check (lint, typecheck, or unit tests) before moving on.

8. Repeat

Go back to step 3 for the next commit. Continue until the working tree is clean or all intended changes are committed.

Deliverable

For each commit, provide:

• The commit message
• A one-line summary (what/why)

Safety Protocol

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