A branch is a named pointer to a commit. With the default ref backend it is a 41-byte file. A worktree is a working directory with a checkout of one, and every worktree has a branch or a detached commit in it. The real choice is not branch versus worktree; it is switching branches in one directory versus keeping several directories checked out at once.
- A branch is a pointer to a commit. It is 41 bytes on disk.
- A worktree is a working directory. Every worktree checks out a branch or a commit.
- You never choose one instead of the other. You always use branches.
- The real question is switching versus several directories at once.
- Switching wins for sequential work, which is most work.
- Worktrees win when the work is genuinely concurrent, which is what agents made normal.
The category error
A branch is a name that points at a commit. A worktree is a directory with files in it. They sit at different layers of git, which is why "should I use a worktree or a branch" has no answer: you use both, always, in every worktree you create.
Two different things, side by side.
| Branch | Worktree | |
|---|---|---|
| Is | A named pointer to a commit | A directory with a checkout |
| Costs on disk | 41 bytes | A copy of your working files |
| Lives in | .git/refs/heads/ or packed-refs | The filesystem, plus a small admin directory |
| How many at once | Thousands, comfortably | A handful, realistically |
| Created by | git branch, git switch -c | git worktree add |
| Can exist without the other | Yes, easily | No. It checks out a branch or a commit |
| Deleting it loses | Nothing, until the reflog expires | Anything uncommitted in that directory |
$ wc -c .git/refs/heads/feature-auth
41 .git/refs/heads/feature-auth
$ cat .git/refs/heads/feature-auth
ad7da8005b8d1a2c9f0e4b7c3d6e9f1a2b3c4d5eThe question people actually mean
Rewrite the query and it becomes answerable: is it better to keep one working directory and switch, or to keep several directories checked out at the same time?
The comparison that has a real answer.
| One directory, switching | Several worktrees | |
|---|---|---|
| Disk used | One checkout | One checkout per worktree |
| Dependencies | Installed once | Installed once per worktree |
| Cost of changing task | Commit or stash, switch, rebuild | cd |
| Two things in flight at once | No | Yes |
| Editor and language server state | Discarded on every switch | Preserved per directory |
| A long test run | Blocks the switch | Runs while you work elsewhere |
| Reviewing a colleague branch | Stash your work first | Open a second window |
| Two agents editing | They collide silently | Isolated |
| Mental overhead | Low: one place to look | Real: N places to remember |
Switching is correct for sequential work, and sequential work is most work. You finish one thing, then start another. One directory is simpler in every respect, your dependencies are installed once, and there is exactly one place to look for anything.
Worktrees are correct when the work is genuinely concurrent: a long build or test run you do not want to block on, a review you need to do without abandoning what you have open, or an agent working on one task while you work on another.
Worktree, stash, or a second clone
Three ways to look at something else without losing what you have. They are not equivalent, and the differences show up under pressure.
| Stash and switch | Second clone | Worktree | |
|---|---|---|---|
| Your work is | On a stack you might forget | Untouched | Untouched |
| Cost to set up | Nothing | A full clone plus install | A checkout plus install |
| Both visible at once | No | Yes | Yes |
| Commits visible in the other | n/a | Only after push and fetch | Immediately |
| Rebuild after moving | Usually | No | No |
| Risk | A forgotten stash entry | Two repos drifting apart | Disk, and directories to track |
Which to use, by situation
The decision, without the theory.
| Situation | Use |
|---|---|
| Finish task A, then start task B | Switch branches |
| Quick hotfix, then straight back | Commit and switch, or a throwaway worktree |
| Review a pull request while keeping your work | Worktree |
| Long test or build run, want to keep working | Worktree |
| Compare two branches side by side in an editor | Worktree |
| Bisecting while continuing to develop | Worktree, with --detach |
| One agent, and you are watching it | Either |
| Two or more agents at once | Worktrees, always |
| Fifty branches you might touch this quarter | Branches. Worktrees are for the two you are on today |
What a worktree actually costs
The reason this question gets asked at all is that branches feel free and worktrees do not. That instinct is correct, but the bill is smaller and more specific than people assume.
What each additional worktree does and does not cost.
| You pay for | You do not pay for |
|---|---|
| A checkout of the tracked files | A second object database |
| A dependency install, unless you share a store | Re-fetching history from the remote |
| A rebuild of anything gitignored | A second set of remotes to keep in sync |
A small admin directory under .git/worktrees/ | Duplicated branches, tags or config |
| One more directory to keep track of | Anything at all when it is idle |
The first two rows are the whole story. Source files are usually a fraction of a repository, because the object database holding every version of them is the large part and it is shared. Dependency directories often are not a fraction of anything, which is why a content-addressed package manager changes the answer: pnpm keeps one global store and hard-links into each worktree, so the second install is near-free in disk terms.
Does each agent need its own branch, or just its own worktree?
Both, and you get the branch for free, because a worktree has to check out something. The only alternative git offers is --detach, and for an agent that is a trap.
| Branch per agent task | Detached HEAD | |
|---|---|---|
| Commits reachable by name | Yes | No |
| Push and open a pull request | Normal | Needs a branch first |
| Survives removing the worktree | Yes | Only as a dangling object |
Shows up in git branch | Yes | No |
| Right for | Any work you intend to keep | Reading a tag, bisecting |
The naming convention matters more than it sounds once several agents are running. Pick a consistent shape, agent/<ticket> or feature/<topic>, and keep the number of path segments constant. Mixing fix and fix/login in one repository produces cannot lock ref errors, because git refs are stored as a directory tree and a name cannot be both a file and a directory.
What agents changed
For most of git history, genuinely concurrent work was rare, because a person does one thing at a time. Worktrees stayed a curiosity for a decade for exactly that reason. Agents removed the constraint, and the concurrency they introduce is the unattended kind: files changing while you are looking somewhere else.
A branch alone does not fix that, which is the practical answer to the question this page is named after. Two agents on two branches in one directory are still two agents in one set of files. The branch is the label on the result; the worktree is the isolation that makes the result meaningful.
Questions people ask
A branch is a named pointer to a commit and costs 41 bytes on disk. A worktree is a working directory with a checkout of one. Every worktree has a branch or a detached commit in it, so they are complementary rather than alternatives.
The question does not resolve that way. You always use branches. The choice is whether to switch between them inside one directory or to check several out at once in separate worktrees.
When the work is genuinely concurrent: a long test run you do not want to block on, a review you need to do without stashing, comparing two branches side by side, or more than one agent working at the same time.
For concurrent work, yes. The checkout is cheap because the object database is shared. The real cost is per-worktree dependency directories, which a content-addressed package manager such as pnpm reduces to hard links.
Yes, with --detach, which checks out a commit directly. It is the right form for reading a tag, reviewing an old release, or bisecting without disturbing the branch you are working on.
For the common case of "I need to look at something else right now", largely yes, and more safely. A worktree leaves your work untouched in its own directory instead of putting it on a stack you might forget. Note that the stash itself is shared across every worktree in a repository.
Yes, or a detached HEAD. Git refuses to check out the same branch in two worktrees, because two directories committing to one ref diverge as soon as either commits.
Three is comfortable and five is a lot. Past that the directories stop being an index of what you are doing and become something you have to maintain, and with agents involved the binding limit becomes how much diff you can actually review.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.