Day 6: Using Claude Code with git

Claude Code can write code, run tests, stage files, and commit — all in one uninterrupted session. That capability is genuinely useful. It's also how you end up with a commit message that says "fix bug" in your main branch history at 11:45pm.

What we tried

We updated our CLAUDE.md with a short git section that Claude Code picks up at the start of every session:

## Git conventions

Branch naming: `feat/`, `fix/`, `chore/` prefix + short-description-in-kebab-case
Commit format: `type(scope): description` — example: `fix(checkout): prevent double submit on slow connections`
Never commit without describing the specific change in the message.
Never push without explicit instruction from a human.
Never use --force or --no-verify flags.
Ask before staging files outside the scope of the current task.

Then we tested what Claude Code would do by default: we gave it a task, watched it complete the code changes, and then asked "stage and commit this." With the conventions in CLAUDE.md, it used the right format. Without them, it wrote whatever seemed natural to it — sometimes good, sometimes "update files."

We also worked out which git operations we're comfortable delegating entirely and which we always want to confirm:

Delegate freely:

• git status — read-only, always fine
• git diff and git diff --staged — read-only, useful for review
• git add <specific files> — staging specific files after reviewing what changed
• git log --oneline — reading history

Always confirm:

• git commit — we want to see and approve the message
• git push — explicit human instruction every time
• git checkout -b — we want to know what branch we're on
• Anything with --force, --hard, or --no-verify

What happened

The main shift was that Claude Code got much better at helping us review before committing. Once it knew our commit format, it would stage the right files, propose a message in the correct format, and stop — waiting for approval. That pause made the commit feel like a decision rather than an event that happened to us.

The thing we didn't expect: Claude Code is genuinely useful at the pre-commit step we'd been doing manually. We'd ask it to run git diff --staged, tell us if anything looked unintended, and summarize what changed in a way we could use as the commit message. It turned a five-minute manual check into a thirty-second one.

The other surprise was scope creep in staging. If you give Claude Code a large task and then say "commit this," it will sometimes stage files that were touched as side effects — a config update, a lockfile change, a neighboring component that got reformatted. Telling it explicitly which files to stage, or asking it to confirm staged files before committing, prevents that.

What we learned

• Specify branch naming convention and commit message format in your CLAUDE.md. Claude Code reads these at session start and applies them consistently. Without them, commit messages drift toward whatever seemed natural at generation time.
• Use "never push without explicit instruction" as a standing rule in CLAUDE.md. Pushing is hard to undo; it should always be a conscious decision. A Claude Code session ending with an automatic push is a session that moved faster than your intent.
• Claude Code handles git status, git add, and git diff confidently and safely — delegate those freely. They're read-only or low-risk. Use them often, especially git diff --staged before every commit.
• Review staged files before committing, not just the diff. Scope creep in staging is subtle — a reformatted file or an unrelated lockfile update looks harmless until you're trying to cherry-pick that commit six months later.
• Never add git push --force, git reset --hard, or git checkout -- . to your allowlist. These operations destroy work and are nearly irreversible. The cost of a confirmation prompt here is trivially low; the cost of a misfire is not.

Next

• Day 7 — Write your first skill from scratch.