When Claude Code is doing most of the implementation, git history gets messy fast. You end up with commits like "fix the thing", "actually fix the thing", "revert fix and try different approach".
Here's the workflow I settled on after a few months of daily Claude Code use.
Work on branches, always
I never let Claude commit directly to main or master. This is more important with AI-assisted development than without because Claude will confidently make changes that seem reasonable but need review.
Standard setup at the start of any session:
git checkout -b feature/[what-we're-building]
Claude automatically respects this. When it suggests commits, they go to the branch.
Tell Claude the commit message style before starting
Add to your CLAUDE.md or the start of a session:
When committing: use conventional commits format.
feat: for new features
fix: for bug fixes
refactor: for refactoring
test: for test-only changes
docs: for documentation
Keep subjects under 72 chars. No period at end.
Without this, Claude writes commit messages like "Updated the authentication function to handle edge cases better by adding null checks and improving error messages" — which is a paragraph, not a commit message.
Atomic commits
Claude's default is to batch everything into one commit when it finishes a task. This makes it hard to see what changed where.
Prompt: "Commit each logical change separately. If you're changing the data model and updating the UI, those are two commits."
For bug fixes: "One commit for the fix, one for the tests."
Review before push
I always run git diff main before pushing, even when I watched Claude make the changes. This catches:
- Accidental deletions Claude didn't mention
- Debug code that wasn't cleaned up
- Changes to files that were out of scope
- Hardcoded values that should be config
The review prompt I use:
Here's the diff: [paste]
Before I push, check:
1. Anything unexpected changed?
2. Any hardcoded values that should be env vars?
3. Any debug/temp code left in?
4. Is the commit message accurate for what actually changed?
PR descriptions
Claude writes good PR descriptions but needs the right prompt:
Write a PR description for this branch.
Include:
- What changed (bullet points, not prose)
- Why it changed
- How to test it
- Any migration steps if needed
Audience: the person reviewing this who didn't see our conversation.
The last line is key. Without it you get PR descriptions that reference "what we discussed" — meaningless to a reviewer looking at it cold.
When things go wrong
Claude occasionally makes a change that breaks something unexpected. Two commands I use constantly:
git stash # save Claude's work, test baseline
git diff HEAD~1 # see exactly what the last commit changed
When I need to revert: "Let's undo the last commit and take a different approach." Claude handles git reset cleanly when you're explicit about it.
The CLAUDE.md git config
Here's what I keep in CLAUDE.md for git:
## Git rules
- Never commit to main directly
- Always use conventional commits
- Atomic commits — one logical change per commit
- Run tests before committing
- No "WIP" commits on branches that will be PRed
- Always include a test commit with implementation commits
Having this in CLAUDE.md means Claude follows the same workflow every session without being reminded.
This git section is part of the larger Agent Prompt Playbook — 50 prompts across 10 categories. The CLAUDE.md templates and PR description prompts are in there. $29.