Git Workflows with Claude Code
Every other subject in this track treats git as background plumbing Claude Code happens to use. This one treats it as the main event. Version control is where an agent's changes stop being ephemeral edits in a session and become durable, reviewable, shared artifacts — a commit someone else will read six months from now, a PR a teammate has to approve, a branch that either merges cleanly or doesn't. Getting this workflow right is the difference between Claude Code as a fast pair programmer and Claude Code as a liability that quietly degrades your repository's history.
The interview-relevant skill here isn't "can you type git commit." It's judgment: knowing what Claude Code can safely be trusted to do with git on its own (read status, draft a commit message, open a PR), what it should always show you before acting on (a force-push, a rebase that rewrites shared history), and how to structure a request so the diff you get back is one you'd be comfortable shipping under your own name. This subject covers the mechanics — how Claude reads git state, how it drafts commits and PRs, how /code-review and /security-review work, how worktrees isolate parallel sessions, how conflicts and rebases get resolved with an agent's help — and the safety discipline that has to wrap around all of it.
Two boundaries worth stating up front: this subject is about driving git locally, from your terminal, in a single Claude Code session. Running Claude Code unattended inside CI (GitHub Actions, GitLab CI/CD, the @claude mention workflow) is covered in the next subject, Headless Mode, CI Automation & the Agent SDK — this one only points at it. And the mechanics of isolating parallel subagents that write to the same repository are covered in the MCP Servers and Subagent Orchestration subject; here, worktrees are discussed from the angle of one human running a few parallel top-level sessions with claude --worktree.
How Claude Code Reads Git for Context
Claude Code doesn't have a special git API — it reads git state the same way it reads anything else: by running the commands you'd run yourself (git status, git diff, git log) through the Bash tool, and reading the output. This matters because it means git context only enters the conversation when something — Claude's own judgment, or your explicit ask — triggers one of those commands. There's no background git-awareness always feeding into every turn.
A few git commands recur constantly as part of the agentic loop from the fundamentals subject:
| Command | What it tells Claude |
|---|---|
git status |
What's staged, unstaged, and untracked right now |
git diff |
Exactly what changed, unstaged, line by line |
git diff --staged |
What's about to be committed |
git log --oneline -20 |
Recent commit history and message style, so a new commit matches the project's conventions |
git log -p -- path/to/file |
The history of a specific file, useful for understanding why a line of code exists |
git blame path/to/file |
Who last touched a line and in what commit, useful for tracking down regressions |
A common pattern: pipe git output straight into a prompt instead of asking Claude to run the command itself. git log --oneline -20 | claude -p "summarize these recent commits" gives Claude only the log, nothing else — useful in scripts, and a preview of the headless patterns the next subject covers in depth.
Reading history before writing to it
Before drafting a commit message, Claude typically runs git log on the touched files first — not out of caution, but because "match the existing style" is only possible if the existing style has actually been read. A codebase that writes fix: handle empty cart and one that writes Fix empty cart bug (closes #482) want different commit messages for the identical diff, and the only way to know which one you're in is to look.