Git Commit
Group all unstaged/untracked changes into atomic commits — one commit per logical concern. A single concern is just the degenerate case: one commit. Never push — pushing belongs to the /ship cycle.
Message Style
Match the repo's existing commit patterns from log.
- Extreme concision — sacrifice grammar for brevity
- Focus on "why" not "what"
- Imperative mood
- Conventional commits when the repo uses them (
feat/fix/refactor/docs/chore+ scope)
Workflow
- Review full diff and status
- Analyze recent commit style from log
- Identify logical groups among the changed files. Common groupings:
- Feature or bug fix (src files implementing one thing)
- Tests for that feature
- Config changes (
package.json,tsconfig, etc.) - Formatting-only changes (no logic change)
- Docs / README updates
- Asset changes (images, fonts, public files)
- For each group:
a. Stage only those files explicitly by name (never
git add .or-A) b. Write a commit message matching repo style c. Commit with HEREDOC format d. Rungit statusto confirm staging is clean before the next group - Run
git statusto verify a clean working tree
Grouping Rules
- Formatting-only changes (whitespace, quotes, indentation) go in their own commit, separate from logic changes
- If a file has both logic and formatting changes, keep them together in the logic commit
- Tests and the code they test can share a commit
Examples
Single concern — one commit:
git add src/auth.ts
git commit -m "fix: null check in login handler"
Multiple concerns — split:
git add src/components/SearchBar.tsx src/hooks/useSearch.ts
git commit -m "feat: add search bar component"
git add README.md
git commit -m "docs: document search usage"
Rules
- NEVER push — pushing belongs to
/ship - NEVER
git add .or-A— stage explicitly by name - NEVER amend unless requested
- NEVER skip hooks
- NEVER commit secrets
Error Handling
- Pre-commit hook fails → fix the issue, re-stage, create a NEW commit (never
--amend) - If unsure how to group a file → ask the user before committing