git worktrees vs branches for parallel AI agents: what actually works

Once you start running more than one Claude Code agent at the same time, git becomes a coordination problem. Two agents cannot share the same working tree without stepping on each other. One of them is editing src/auth.ts. The other also needs to edit src/auth.ts. One of those edits disappears unless you do something about it.

The two common answers are: branches (switch or clone) and git worktrees. They sound similar - both give each agent its own branch - but they differ in how the filesystem works and what the merge story looks like. The choice matters more than most practitioners realize, because the wrong one becomes overhead at five agents that was invisible at two.

This is a practitioner comparison. The goal is an honest verdict on each, not a pitch for either.

The branch approach

The simplest version: each agent gets its own branch, and you manage the filesystem by giving each agent its own directory - either a separate clone of the repo, or just a manually maintained second checkout. Three agents, three directories, three branches. Each directory is a full copy of the repo at the point you branched from.

This works, and for teams running one or two agents on any given day it is perfectly adequate. The problems surface as you scale:

• Disk and clone overhead. Separate clones mean separate .git directories, separate object stores, and a fresh network pull for each. On a large repo this is not free.
• Stale starting points. If you clone and branch at 9am and agent B runs until 4pm, its starting point is 7 hours old. Another agent may have merged changes that B's branch is now diverging from.
• No shared object store. Git cannot deduplicate objects across separate clones. Worktrees share the same object store, so a commit in one is immediately visible in another without a fetch.

The branch approach is also the only one available inside a single checkout: git stash, switch branches, run the agent, git stash pop, switch back. This is not parallelism - it is time-sharing. One agent runs while the others wait. For most people hitting this pattern, it is a sign to reach for worktrees.

The worktree approach

git worktree add ../my-feature-worktree my-feature-branch creates a new working directory linked to the same .git folder. The worktree has its own HEAD, its own index, and its own set of tracked files. It checks out a different branch than the main working tree. Two worktrees can exist simultaneously and both be actively written to. They share the same object store, so a commit in one is immediately accessible in the other via the normal ref names - no fetch needed.

For parallel agents this is the right primitive. Each agent gets a directory. Each directory is a worktree on its own branch. The agents write files, run tests, and commit - all simultaneously, without touching each other's working trees. The shared .git means they see each other's commits the moment they exist.

Where worktrees win decisively:

• True parallelism. Multiple agents writing files at the same time, no stashing, no switching. Each agent's writes are in its own directory.
• Shared object store. No clone overhead. Adding a worktree is fast - it checks out an existing branch into a new directory, reusing the existing repo objects.
• Each agent sees the shared history. If you want agent B to know what agent A just committed, git log in B's worktree shows A's commits on their branch immediately, without a remote roundtrip.

Where worktrees add friction:

• Cleanup. Worktrees accumulate. A session that spawned five agents and then crashed leaves five worktree directories and five branches. They do not clean themselves up. You need a discipline around git worktree remove and git branch -d, or they pile up.
• Merge sequencing. Five agents finishing simultaneously still need their branches merged into main sequentially. If agents A and B both modified src/api/routes.ts, you have a conflict at merge time regardless of how clean the parallel execution was. The isolation is at the filesystem layer during execution. It does not dissolve the underlying merge problem.
• Branch proliferation. Each worktree requires a unique branch. At scale you end up with a lot of short-lived branches. This is manageable with naming conventions but it is not automatic.

The merge problem both approaches share

Here is the part that does not appear in most comparisons of these two approaches: the worktree vs branch question is a filesystem isolation question, not a coordination question. Both approaches give each agent its own branch. The hard part - which neither solves - is what happens when those branches reconverge.

Merge conflicts are the obvious case, and they get enough attention. But there are subtler problems:

• Interface drift. Agent A spent the morning refactoring the data layer, moving to a repository pattern. Agent B, working in its own worktree, kept building against the old direct-query approach. Both branches compile cleanly. The merge produces code that compiles but has two incompatible patterns for the same concern - and the conflict detector missed it because the files did not overlap.
• Duplicated decisions. Both agents hit the same cross-cutting question - say, how to handle authentication errors - and each made a reasonable call. Now you have two different error-handling approaches in one codebase.
• Merge ordering matters. If you have five worktree branches to merge, the order you merge them in affects what conflicts surface. The first merge goes cleanly. The second might conflict. The third conflicts with the resolution from the second, not the original code. This is annoying to reason about without tooling.

None of this is a failure of worktrees. It is a property of parallel work in any medium: the coordination problem does not live at the filesystem layer. It lives at the decision layer.

Sequencing merges from worktrees

For teams running four or more agents regularly, a merge sequencing practice matters more than which isolation primitive you pick. A few patterns that work:

Merge the simplest branches first

Order merges by scope. The branch that touched the fewest files and made the most bounded changes goes first - it is least likely to conflict with anything, and its merge gives you an updated base for the remaining branches to resolve against. Save the widest-ranging branch for last, when the full context of what others did is already in main.

Settle shared interfaces before agents fan out

The highest-leverage practice is not a merge strategy - it is a decomposition strategy. Before spawning agents in parallel, spend time upfront resolving the interfaces they will share. If agent A and agent B will both touch the auth layer, decide the auth layer's shape before either starts. Agents working against a fixed interface do not conflict at the design level, only at the line level. See keeping context consistent across parallel agents for the fuller treatment of this problem.

Designate a merge-last branch for refactors

Refactors that touch many files should be isolated from feature branches until the end. Running a refactor in parallel with four feature branches is a recipe for conflicts. Give the refactor its own worktree, merge the feature branches first, then apply the refactor to the merged result. It is a bigger rebase, but a predictable one.

A note on tooling that wraps worktrees

Several tools in the parallel-agent space have settled on worktrees as the underlying primitive and added a management layer on top: automatic worktree creation per task, branch naming, cleanup on session close, and visibility into which agent is in which worktree. Our own write-up on the Claude Code worktree workflow covers the mechanics in depth, including the ceiling you hit at roughly three to four agents when manual worktree coordination becomes its own overhead. The tools exist on a spectrum from raw git worktree (maximum control, zero help) to fully managed (less overhead, less visibility). Which point on that spectrum is right depends on how many agents you are running and how often the tasks overlap in scope.

The tooling question is secondary to the practice question. A team that has not settled how to decompose tasks and sequence merges will hit problems regardless of whether they use raw worktrees or a managed wrapper. A team that has the decomposition right will find both workable.

The deeper constraint

The worktrees vs branches debate is worth having, and worktrees are usually the right answer for true parallel execution. But practitioners who resolve the isolation question and then stop tend to find the same problems surfacing in a different form: agents that each did good work producing a codebase that does not quite cohere, because the shared decisions were never shared.

The constraint that neither git primitive addresses is the shared decision layer: where does the decision made at 9am live so that the agent started at 2pm honors it, without you being the thing that carried it there? That is where the approaches that go beyond raw worktrees - gated planning stages, shared memory, structured decomposition - add something the git layer cannot. defract is one approach to that layer: settling the design and architecture before implementation fans out, and keeping the shared decisions somewhere other than the developer's working memory. The git isolation (worktrees, in our case) is still doing its job; it is just not doing the whole job. For more on the patterns that hold up across codebase sizes, see which agentic coding patterns actually scale.