Claude Code and git: the workflow that keeps your history clean

Left to itself, Claude will batch changes and commit at the end of a task. Sometimes that's fine. For longer tasks or anything you might need to roll back, it produces one large commit that mixes multiple logical changes — which is hard to review and hard to undo selectively.

Tell Claude when and how to commit

Add commit instructions to your task prompt: "Commit after each logical unit of work. Each commit should contain one coherent change with a descriptive message. Do not batch multiple changes into one commit."

What counts as "one logical unit" depends on the task. For a feature: commit the data model separately from the API endpoint separately from the tests. For a refactor: commit the extraction separately from the cleanup separately from the update of call sites.

Commit message format

Claude writes generic commit messages unless you specify a format. "Add new function" and "Fix bug" are examples it defaults to. Specify the format in CLAUDE.md or in the task prompt:

Commit message format:
- First line: verb + what changed (50 chars max)
- Example: "Add rate limiting to /api/posts endpoint"
- Do not include "feat:", "fix:" prefixes unless I ask
- No co-authored-by lines

Review before commit, not after

The default Claude workflow is: build the thing, commit, done. The better workflow: build a step, review it, then commit. This means telling Claude to pause after each logical unit and wait for your confirmation.

"After you finish [step], show me what you changed before committing. I'll tell you when to proceed." This takes more back-and-forth but produces a history that's clean by design rather than cleaned up later.

Handling Claude's accidental changes

Claude sometimes modifies files that were in scope but shouldn't have been changed (a config file touched while working on the API, a utility function refactored while working on something that uses it). Before committing, run git diff --name-only and verify every file is expected.

If there are unexpected files: git restore [file] to undo just that file, then continue. Don't commit and clean up later — the history gets messy and the "what was actually changed for this feature" question becomes hard to answer.

Branch per task

For anything more than a small fix: work on a branch. Tell Claude "create a branch called [name] for this task before starting." This isolates the changes, makes the diff easier to review, and gives you a clean rollback path.