Simon Willison recently published a section of his agentic engineering patterns guide focused specifically on git workflows with coding agents. It covers commit discipline, branch hygiene, and a few recovery patterns. The advice is sound, but there is a wider story worth telling about how git’s role fundamentally changes once you have an agent in the loop.
When you write code yourself, git is a historical record. Commits document decisions; branches isolate features; diffs explain changes to reviewers. The mental model is archival. When a coding agent writes code, git becomes something different: active safety infrastructure. The commits are checkpoints you can roll back to, the branches are isolation boundaries for experiments, and the history is context you inject into the agent to prevent it from contradicting its own previous work. The tool is the same but the usage pattern shifts considerably.
Commit Discipline Changes Meaning
Willison’s “atom everything” principle asks you to commit after each discrete unit of agent work, even small ones. The rationale is straightforward: if you commit after every logical step, you can git reset --hard HEAD to instantly undo the last thing the agent did without manually identifying which files changed across a long session.
This is a different reason to commit than developers usually have. Normally, commit granularity is a question of readability for future reviewers. With agents, it is a question of rollback fidelity. The smaller the commit, the more precisely you can recover from a mistake.
The workflow this implies:
# Start clean on a branch
git checkout -b agent/auth-rewrite
git status # must be clean before the session starts
# After each logical agent step
git add -p # review hunks interactively
git commit -m "[AI] add JWT validation to middleware"
# If the agent goes sideways
git reset --hard HEAD # back to the last checkpoint
git diff HEAD~1 # inspect what the previous step didThe git add -p step is not optional. Agents create files outside the stated scope of a task, add debug statements they forget to remove, and occasionally write changes to the wrong file entirely. Reviewing hunks interactively before staging is the primary human checkpoint in the loop.
Some developers prefix AI-assisted commits with [AI] or use git’s --trailer flag:
git commit --trailer "Co-Authored-By: Claude <noreply@anthropic.com>" -m "implement rate limiting"This builds an auditable record of which parts of the codebase have AI-authored code, useful for teams with compliance requirements or who want to be able to audit AI contributions during security reviews.
Git Worktrees: The Pattern Most Developers Skip
Git worktrees are the feature here that genuinely changes what is possible with coding agents. A worktree lets you check out multiple branches of the same repository simultaneously, each in its own directory, with fully independent staging areas, stashes, and working states.
git worktree add ../project-auth -b agent/auth-rewrite
git worktree add ../project-tests -b agent/test-coverage
git worktree add ../project-db -b agent/db-refactor
git worktree list
# /home/user/project abc1234 [main]
# /home/user/project-auth 000000 [agent/auth-rewrite]
# /home/user/project-tests 000000 [agent/test-coverage]
# /home/user/project-db 000000 [agent/db-refactor]Now three separate agent sessions can run simultaneously on the same repository, each in its own directory, with zero interference. Each sees a clean git status. Each can stage, stash, and commit independently. When one session finishes, you review its diff, merge or discard it, and clean up:
# Review the work
cd ../project-auth
git diff main...HEAD --stat
git log --oneline main..HEAD
# Either merge it
git -C ~/project merge agent/auth-rewrite
# Or discard it entirely
git worktree remove ../project-auth
git branch -D agent/auth-rewriteWithout worktrees, running two Claude Code or Aider sessions on the same repository requires careful coordination to avoid stomping on each other’s unstaged changes. With worktrees, isolation is structural. The directories are separate. There is nothing to coordinate.
Claude Code’s tool set includes an EnterWorktree tool precisely because this pattern is valuable enough to build into the tooling directly. The agent can spin up its own isolated workspace, do its work, and hand back a clean diff for review.
For long-running or speculative tasks, creating a worktree per task is a sensible default:
TASK="implement-search"
git worktree add /tmp/agent-${TASK} -b agent/${TASK}
# run agent session in /tmp/agent-${TASK}If the approach does not pan out, git worktree remove /tmp/agent-${TASK} and you are back to a clean state in under a second.
How Different Tools Handle Git
Not all coding agents treat git the same way, and understanding the differences matters for choosing a workflow.
Aider has the most opinionated git integration. It auto-commits after every accepted change by default, generating a commit message describing the modification. This is convenient but means you lose the git add -p review step unless you pass --no-auto-commits. Aider also maintains a “repo map” built from git ls-files, which gives the model a structural index of all tracked files without loading them into context. This is a clever use of git as a codebase discovery mechanism.
Claude Code leaves commit decisions to the human by default. It runs git status, git diff, and git log autonomously to understand repository state, but will not stage or commit without instruction. Its built-in safety protocol explicitly avoids git push --force, git reset --hard, and --no-verify unless the user asks for them. It also avoids git add -A and git add ., preferring to stage specific files. These constraints exist because an agent with broad git access can rewrite history or discard work faster than a human would notice.
Cursor’s agent mode shows diffs in the UI before applying them. The human clicks “Apply” to write changes to disk, which means nothing reaches the filesystem until reviewed. Cursor does not auto-commit. The git interaction is entirely controlled by the developer after applying changes.
Copilot Workspace takes a different approach entirely: it proposes changes in an isolated cloud environment, not your local working tree. The output is a pull request, not a branch diff. The isolation is handled at the infrastructure level rather than through local git primitives.
Each approach reflects a different trust model. Aider trusts you to review commits after the fact. Claude Code defers to you before committing. Cursor requires approval before changes even touch disk. Copilot Workspace removes local git state from the equation entirely.
Git History as Agent Context
One pattern that does not get enough attention: feeding git history back into the agent as context.
Agents working on long-running features or multi-session projects benefit from seeing recent commit history. Without it, they may duplicate work done in a previous session, contradict a design decision made two days ago, or miss that a dependency was already refactored.
git log --oneline -20
git log --oneline --all --graph
git diff main...HEAD --statPassing the output of git log --oneline -20 at the start of a session gives the agent a timeline of recent decisions. git show <hash> lets the agent inspect what a specific commit did and why, assuming commit messages are descriptive. This transforms git history from a record for human reviewers into live context for the agent.
For teams doing serious agentic development, this suggests that commit message quality matters more than it used to. A terse message like “fix bug” tells a future agent nothing. A message like “fix null pointer in auth middleware when session token is expired” gives the agent enough to avoid stepping on the same ground.
Pre-Commit Hooks as the Safety Layer
Pre-commit hooks pair well with agentic workflows because they run automatically before every commit, catching errors the agent introduced without requiring the human to spot them manually. Tools like pre-commit, husky, and lefthook can enforce linting, formatting, secret scanning, and type checking as a precondition of committing.
If an agent stages a file that introduces a linting violation or accidentally includes an API key, the commit fails and the hook output tells you exactly what went wrong. This shifts some of the review burden from the human’s eyes to automated tooling, which is appropriate given the volume of changes agents can produce in a short session.
One important note specific to agents: when a pre-commit hook fails, the commit did not happen. If you then run the fix and want to commit again, you must create a new commit, not amend the previous one. Amending in this context would modify the last successful commit, not retry the failed one, which can silently corrupt history. Claude Code’s safety protocol explicitly calls this out; other tools do not always make it clear.
The Underlying Shift
The common thread through all of this is that agentic development makes git usage more demanding, not less. Agents move fast, create many files, and are happy to overwrite things. The developer’s job shifts toward reviewing diffs rather than writing code, and git is the primary interface for that review. Worktrees enable parallelism. Atomic commits enable precise rollback. Branch isolation enables experimental work without risk to the main codebase. History enables cross-session context for the agent.
Git was designed for collaboration between humans working asynchronously. It turns out to be a surprisingly good fit for collaboration between a human and one or more autonomous agents working on the same codebase, but only if you use more of its features than most developers typically reach for.