osherboudara99 Incremental Commits
This user wants git history that reads like a story of small, reviewable steps — not a handful of giant commits. Small commits make it easy to spot where something broke, to revert just one piece, and to review a diff without wading through unrelated changes.
When this applies
Any time you're doing development work in a git repository for this user: implementing a feature, fixing a bug, refactoring, updating config, editing docs, bumping dependencies, touching CI. This is a standing preference, not something to wait to be told each time — treat "let's build X" as implicit authorization to commit as you go, the same way the user would if they were typing the commands themselves.
This does not apply to throwaway exploration, scratch files outside a repo, or repos where the user has said not to commit.
How to work
- Break the task into logical steps before you start (a plan or todo list helps). Each step should be a coherent, working unit — e.g. "add the validation function," "wire up the new endpoint," "update the config schema." Not "save file" granularity, and not "the whole feature" granularity.
- After finishing each step, stage only the files relevant to that step and commit immediately. Don't let multiple unrelated changes pile up uncommitted.
- Don't wait until the end of the task to commit everything at once — that defeats the purpose. If you catch yourself with a large uncommitted diff spanning several concerns, that's a sign to have split it up already; stop and commit what's ready before continuing.
- Follow the same safety rules as always: check
git status/git diffbefore committing, never use--no-verifyor skip hooks, never force-push, and only commit files that belong to the current step.
Commit message format
Use conventional-commit-style prefixes, short and to the point — a single line describing what changed, not why in depth (save "why" for the PR description if there is one).
Prefixes to use:
feat— new functionalityfix— bug fixrefactor— code change that doesn't change behaviordocs— documentation onlyci— CI/CD pipeline or workflow changesdeps— dependency additions/updates/removalschore— everything else (tooling, config, cleanup)test— adding or updating tests
Format: <prefix>: <short imperative description>
Examples:
feat: add email validation to signup formfix: handle null response from payment APIrefactor: extract retry logic into helperdocs: document the new config flagsci: cache node_modules in build workflowdeps: bump requests to 2.32.0chore: remove unused imports
Keep the subject line short (aim for under ~60 chars). Only add a body if a one-liner genuinely can't convey what changed — and if so, keep it to a line or two, not a paragraph.
Co-authorship
Do not add a Co-Authored-By trailer, or any other Claude/Anthropic attribution line, to commit messages.