Git Worktrees vs Branches: A Complete Guide for Developers and AI Coding Agents

If you’ve been using Git for any length of time, branches feel second nature — create one, switch to it, do your work, merge it back. But there’s another Git feature that’s been quietly sitting in the toolbox since Git 2.5 that many developers have never touched: worktrees. And with AI coding agents like Claude Code entering the picture, understanding the difference between the two has never been more relevant.

This post breaks down how Git actually works under the hood, what branches and worktrees are, how pull requests fit into both models, and why worktrees are increasingly the right choice when you’re running AI agents on your codebase.

How Git Actually Works

Before comparing branches and worktrees, it helps to understand what Git is actually doing when you use it.

At its core, Git is a content-addressable filesystem. Every file, directory snapshot, and commit is stored as an object identified by a SHA-1 hash. When you make a commit, Git doesn’t store a diff — it stores a complete snapshot of every tracked file at that moment (though it deduplicates unchanged files efficiently).

Your repository has three key areas:

The object store (.git/objects/) — where all your commits, trees, and file contents live, permanently.
The index (staging area) (.git/index) — a snapshot of what will go into your next commit.
The working tree — the actual files on disk that you edit.

A branch is nothing more than a file in .git/refs/heads/ containing a single SHA-1 hash — the commit it currently points to. That’s it. When you commit, Git moves that pointer forward automatically. Branches are extraordinarily lightweight.

Branches: The Standard Model

The classic Git workflow is branch-based. You have one working directory, and you switch between branches using git checkout or git switch. Git swaps out the files in your working directory to match whichever branch you’re on.

git checkout -b feature/my-new-thing
# ... do work ...
git add .
git commit -m "Add my new thing"
git push origin feature/my-new-thing

This works brilliantly for a single developer doing one thing at a time. The friction appears when you need to context-switch mid-flow. You’re deep into a feature, a critical bug comes in on main, and now you need to stash your work, switch branches, fix the bug, switch back, pop your stash, and re-orient yourself.

Branches also share your single working directory — so a long-running build or test on one branch blocks you from switching until it’s done (or you interrupt it).

Worktrees: Multiple Working Directories, One Repository

A worktree lets you check out a branch into a completely separate directory on disk, while still sharing the same underlying .git folder — the same object store, the same history, the same remotes.

# Add a worktree for a hotfix branch, in a sibling directory
git worktree add ../my-project-hotfix hotfix/critical-bug

# Now you have:
# ~/my-project/          ← main branch, your normal workspace
# ~/my-project-hotfix/   ← hotfix branch, separate directory

Both directories are live at the same time. You can open them in separate editor windows, run separate build processes, and commit to each independently. They share no working tree state — editing a file in one has zero effect on the other.

Key worktree rules to know:

A branch can only be checked out in one worktree at a time. Git enforces this to prevent conflicts.
Worktrees are listed with git worktree list and removed with git worktree remove <path>.
You can create a worktree with a new branch in one command: git worktree add -b new-branch ../new-branch-dir.
All worktrees see the same commits, tags, and remotes instantly — there’s no syncing needed between them.

Pull Requests in Both Models

Pull Requests (PRs) — or Merge Requests in GitLab — are a workflow layer built on top of Git, typically provided by your hosting platform (GitHub, GitLab, Bitbucket). The underlying Git mechanics are identical regardless of whether you used a branch in a single worktree or a dedicated worktree — what matters is that you have a branch pushed to a remote.

The PR lifecycle

You create a branch (with or without a dedicated worktree) and push it to the remote.
You open a PR from your branch into the target branch (usually main or develop).
Reviewers comment, request changes, and approve.
The PR is merged — either via a merge commit, squash, or rebase, depending on your team’s preference.
The branch (and associated worktree, if any) is cleaned up.

Where worktrees change the experience

With the traditional branch model, reviewing someone else’s PR typically means stashing your current work, fetching their branch, checking it out, running the code, and then switching back. With worktrees, you can add their PR branch as a separate worktree:

git fetch origin pull/42/head:pr-42
git worktree add ../review-pr-42 pr-42

Now you can run their code in a separate directory while continuing to work in your main worktree — no stashing, no context switching, no interruption.

Worktrees and AI Coding Agents: Why It Matters

This is where things get particularly interesting in 2025.

AI coding agents like Claude Code, Cursor, and similar tools are increasingly being used to run parallel, autonomous development tasks — writing features, fixing bugs, running tests — with minimal human intervention during execution. The branch model creates a fundamental bottleneck here: you can only have one branch checked out in a working directory at a time.

If you want to run three AI agents simultaneously working on three different tasks, you have three options with the branch model:

Run them sequentially (slow, defeats the purpose).
Clone the repository three times (wastes disk space, breaks object sharing, creates sync headaches).
Use worktrees.

Worktrees are the clean solution. Each agent gets its own worktree — its own isolated working directory — but they all share the same Git object store. An agent working in ../agent-feature-auth and an agent working in ../agent-feature-payments are completely independent at the file level but share history and remotes seamlessly.

A practical AI agent workflow with worktrees

# Spin up three agents, each in their own worktree
git worktree add -b agent/auth-system ../project-auth
git worktree add -b agent/payments-api ../project-payments  
git worktree add -b agent/ui-redesign ../project-ui

# Launch agents in each directory
# Each agent can commit, push, and open PRs independently
# When done, clean up
git worktree remove ../project-auth
git worktree remove ../project-payments
git worktree remove ../project-ui

Each agent’s work ends up on its own branch, which can be reviewed and merged via a normal PR process. The human stays in the loop at the review stage without having been the bottleneck during development.

Isolation and safety

Another advantage for AI workflows: worktrees provide a natural isolation boundary. If an agent makes a mess of its working directory — creates unexpected files, runs a build that generates a lot of output — it’s entirely contained to that worktree. Your main working directory is untouched. You can simply remove the worktree and start fresh without any cleanup risk to your main workspace.

Branches vs Worktrees: A Quick Comparison

	Branches (single worktree)	Worktrees
Working directories	One	Many
Context switching	Requires stash or commit	Just switch directory
Parallel work	Not possible in same repo	Native support
Disk usage	Single working copy	One working copy per worktree
Object store	Shared	Shared
PR workflow	Identical	Identical
AI agent support	One agent at a time	Multiple concurrent agents
Complexity	Simple	Slightly more to manage

When to Use Which

Stick with the standard branch model if you’re a solo developer doing one thing at a time, your workflow is simple, or you’re new to Git and don’t want to add mental overhead. The branch model is tried, tested, and well-understood by every tool in the ecosystem.

Reach for worktrees when you need to work on multiple things simultaneously without stashing, when you want to review a PR without abandoning your current work, when you’re running long builds or tests that shouldn’t block your editing, or — critically — when you’re running multiple AI coding agents in parallel.

Getting Started

Worktrees require Git 2.5 or later (released in 2015, so almost certainly available on your system). The core commands are simple:

# List all worktrees
git worktree list

# Add a worktree on an existing branch
git worktree add ../path-to-new-dir branch-name

# Add a worktree and create a new branch
git worktree add -b new-branch-name ../path-to-new-dir

# Remove a worktree (branch is not deleted)
git worktree remove ../path-to-new-dir

# Clean up stale worktree references
git worktree prune

The mental shift is small but the productivity gain — especially once you start working with AI agents — is significant. Branches tell you what line of work you’re on. Worktrees give you where to actually do that work, simultaneously, without compromise.