Git for AI Agent Teams: Branching, Review and Provenance When Most Commits Aren't Human

One of the most-discussed posts on daily.dev this week asks a question that sounds philosophical and turns out to be purely operational: Git was built for humans — what happens when your dev team is mostly agents? AI coding agents now open pull requests, fix failing CI, refactor modules and update dependencies. They produce changes faster than any human team can read them. And they do it inside a version-control system whose every assumption — authorship, commit messages, code review, blame — was designed around people.

We run multi-agent workflows in our own automation practice, and the lesson arrived quickly: the first thing that breaks is not Git itself. It is the workflow around Git. This article is the practical version of the trend: what actually breaks when agents join the team, and the concrete Git practices — isolation, commit discipline, review tiers, provenance — that keep a human–agent codebase healthy. It is the same philosophy as how we work: automate the routine aggressively, and spend human judgment exactly where it changes the outcome.

1. The assumptions Git makes about you

Git was designed in 2005 for a very specific social structure: a network of trusted human maintainers exchanging patches. Its workflow layer (the part your team adds on top: branches, PRs, reviews) quietly assumes:

• Authors are identifiable and accountable. A commit has a person behind it who can answer "why?"
• Commit messages carry intent. Humans write messages for other humans, however imperfectly.
• Review bandwidth scales with authors. If ten people write code, roughly ten people can review it.
• History is written at human speed. A busy team produces dozens of commits a day, not hundreds.

Agents violate all four. An agent's "intent" lives in a task specification and a conversation, not in its head. Its output scales independently of your review capacity. And left alone, two agents will happily edit the same files in the same working tree, producing a merge situation no human would create. The fix is not a new tool — agents work fine with plain Git. The fix is tightening the workflow at exactly the points where the assumptions crack.

2. What breaks first (and it is not merge conflicts)

Teams new to agent workflows expect conflict chaos. In practice, the failures arrive in a different order:

1. Review throughput. Agents generate plausible-looking diffs at machine speed. Human review — the actual quality gate — becomes the bottleneck within the first week. Everything else in this article is downstream of this fact.
2. Diff size. An agent asked to "fix the bug" may refactor five files on the way. Large diffs get rubber-stamped, which is worse than no review because it creates false confidence.
3. Commit messages without a "why". Agents summarize what changed fluently. The reasoning lives in the task prompt, which is not in your repository — six months later, git log cannot tell you why a change exists.
4. Shared working trees. Two agents (or an agent and a human) in one checkout will stage, stash and commit over each other. This is the one genuinely Git-level failure, and it is entirely preventable.
5. Attribution mush. If agents commit under a human's identity, blame, audit and access control all degrade at once — you can no longer answer "who or what touched the payment code?"

3. Isolation: one worktree per agent, never a shared checkout

The single highest-leverage practice: every agent works in its own Git worktree on its own branch. A worktree is a separate working directory backed by the same repository — cheap to create, fully isolated files, shared object store:

# Give each task its own workspace + branch
git worktree add ../wt-fix-checkout-timeout -b agent/fix-checkout-timeout
git worktree add ../wt-bump-dependencies   -b agent/bump-dependencies

# List and clean up when tasks finish
git worktree list
git worktree remove ../wt-fix-checkout-timeout

Rules that make this work:

• Branch per task, named for the task: agent/<task-slug>. The branch name is the first piece of provenance.
• No shared checkouts, ever. Not between two agents, not between agent and human. Most "agent corrupted my work" stories are shared-working-tree stories.
• Disposable by default. If an agent's branch goes sideways, delete the worktree and restart the task from a clean base. Restarting is cheap; untangling is not.
• Partition tasks to avoid collisions. Two agents refactoring the same module in parallel will conflict no matter how good your process is. Split work by module or by layer (schema / API / UI), the same way you would for humans who cannot talk to each other.

4. Commit discipline for machines

Agents should commit more strictly than humans, not less, because their history will be read during incident response:

• Small, atomic commits. One logical change per commit, enforced by task design ("implement, test, commit" as separate steps). Atomic commits are what make git bisect and clean reverts possible later.
• Structured messages with machine-readable trailers. The subject describes the change; the body links the task; trailers carry provenance:

Fix checkout timeout by retrying token refresh once

Retry logic added to the payment session client; falls back to
a fresh token on 401 instead of failing the checkout.

Task: checkout-timeout-2026-10-21
Agent: builder-2
Verified: unit tests 42/42, staging smoke check

Git trailers (git commit --trailer "Agent: builder-2") are parseable with git interpret-trailers, so provenance stays queryable instead of becoming folklore.

• A distinct identity per agent (or per agent role). Agents commit as a bot identity, never as a human team member. On GitHub this means a machine user or GitHub App with scoped permissions — least privilege per repository, no admin, no force-push rights.
• No force-push to shared branches. Agents rebase their own task branches freely; shared branches (main, release) are append-only and protected.

5. Review is the bottleneck: tier it, gate it, shrink it

Since review capacity is the constraint, design for it explicitly:

• Shift verification left, into machines. Tests, type checks, lint, security scans and build must pass before a human ever sees the diff. Treat the test suite as the contract the agent works against — the same evidence-over-opinion discipline we apply in data pipelines, where a validation stage records what was actually checked rather than a vibes-based score (see our breakdown of email validation evidence layers).
• Cap diff size. A PR above an agreed size (say, a few hundred changed lines) gets split or escalated — never silently merged. Size caps are crude and extremely effective.
• Tier by risk, not by author. Documentation, tests and dependency bumps with a green pipeline can auto-merge. Anything touching auth, payments, data migrations or infrastructure gets mandatory human review — enforced mechanically with CODEOWNERS on sensitive paths, not by convention.
• Review the task spec, not just the diff. For agent work, the highest-value human read is often the instruction and the verification evidence ("what did you run, what passed?") rather than every generated line.

6. Provenance and the revert-first culture

When something breaks at 2 a.m., agent-era Git hygiene pays off in three ways:

• Blame still works — if commits are atomic and honestly authored, git blame and git log -L point at the exact change and, via trailers, at the task that produced it.
• Bisect still works — git bisect run ./test.sh can binary-search a regression across hundreds of agent commits only if each commit builds and is one logical change. This is the concrete return on commit discipline.
• Reverts are cheap and shame-free. With agents, the fastest fix is often git revert <sha> and re-dispatch the task with a better spec, instead of hand-patching generated code. Design for this: feature flags for agent-shipped behavior, reversible migrations, and no manual edits on top of agent branches that a revert would erase.

Keep the task specification itself with the code: a short spec file committed alongside the change (or linked from the commit body) means the "why" survives even when the chat that produced it is long gone.

7. A pragmatic workflow, end to end

Putting it together, a sane human–agent Git workflow looks like this:

1. Human writes a task spec with explicit acceptance checks.
2. System creates a worktree + agent/<task> branch from a clean main.
3. Agent works in isolation: small commits, structured messages, bot identity.
4. Agent runs the full verification suite; evidence is attached to the PR.
5. Automation enforces the gates: green CI, diff-size cap, CODEOWNERS for sensitive paths.
6. Human reviews at the risk tier the change earned — skim the auto-verified, read the critical.
7. Merge to a protected main; branch and worktree are deleted.
8. Anything that misbehaves in production is reverted first and re-dispatched with a better spec.

None of this requires new tooling. It requires admitting that the scarce resource moved: code production is now abundant, and verified, reviewable, reversible change is the thing your workflow must manufacture.

8. Frequently asked questions

Do agents need their own GitHub accounts?
Effectively, yes — a bot identity (machine user or GitHub App) per team or per role. It keeps permissions scoped, audit logs honest, and human blame meaningful.

Should agent commits be signed?
Signing proves which key produced a commit, which is genuinely useful once multiple agents and automations write to the same repo. Bot identities with managed keys (e.g., GitHub App–generated commits are marked verified) give you most of the value with little ceremony.

How do you review fifty agent PRs a day?
You don't — that is the point of tiering. Most agent PRs should be small, mechanically verified and auto-mergeable; human attention concentrates on the risky minority. If everything needs deep human review, the agents are producing the wrong size of change.

What about two agents editing the same file?
Prevent it structurally: separate worktrees, task partitioning by module, and short-lived branches. Conflict resolution heroics are a symptom of missing isolation, not a workflow.

References

• Git worktree documentation: https://git-scm.com/docs/git-worktree
• Git trailers (git interpret-trailers): https://git-scm.com/docs/git-interpret-trailers
• Pro Git, "Git Branching — Branches in a Nutshell": https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell
• GitHub Docs — protected branches: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• GitHub Docs — CODEOWNERS: https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

---

Originally published on botslave.com. Botslave is an automation studio — see what we build and how we work.

Comments

[Vishisht Choudhary]

Review throughput breaking before merge conflicts do rings very true once you have a few agents in one repo. One cheap provenance trick is commit trailers like Agent: claude-code and Task: <id>. git log --format='%(trailers)' can search them with no extra tooling. Do you set review tiers by diff size, or by which paths a change touches?