Git Worktrees: A Desk per Branch

I used to work on several branches the way most people do: one clone, lots of git stash. Halfway through a refactor, an urgent fix comes in. Stash, check out main, branch, reinstall dependencies because the lockfile changed, fix, push, check out the refactor, pop the stash, hope nothing conflicts. Sometimes I’d realise an hour later I’d been editing the wrong branch.

The fix I’ve used for years now is boring and built into git: worktrees.

The idea

A worktree is an extra working directory attached to the same repository. Each one has its own branch checked out, its own files on disk, its own node_modules and its own running dev server — but they all share one .git store, so there’s nothing to clone or download.

git worktree add ../myapp-hotfix -b fix/login-redirect main   # new branch, new directory
git worktree list                                              # what am I juggling?
git worktree remove ../myapp-hotfix                            # done with it

That urgent fix becomes:

1. Create a worktree for the fix.
2. Fix it, test it, push it.
3. cd back to the refactor, exactly as you left it.

No stash. No reinstall. No half-finished code moving between branches.

Why it beats multiple clones and stashing

• Instant. Creating a worktree is a local checkout, not a network clone.
• Your editor stays warm. IDEs that re-index on every branch switch don’t have to — each directory keeps its index.
• Old branches stay tidy. Checking out an ancient branch in your main clone can surface files that are now ignored; in its own worktree, that mess stays contained.
• It’s safe. Uncommitted work never moves. The paranoia of “did that stash pop correctly?” goes away.
• The list keeps you honest. git worktree list is effectively your work-in-progress board. If it’s long, you’re doing too much at once.

My workflow, then and now

When I first wrote about this I’d wrapped it in three shell scripts bound to keyboard shortcuts: one to create a branch from a naming template off the up-to-date main branch, one to fuzzy-find a branch and create a worktree for it, and one to open a dedicated tmux session per worktree. Jumping between pieces of work took a couple of keystrokes.

A later habit stuck even more: one worktree per open pull request. When a few PRs are in review at once, each lives in its own directory with its own app running. Addressing review comments is a cd, not a context rebuild. Keeping each one current is a merge from main and a quick test, then on to the next.

The 2026 twist: worktrees for agents

The surprise is how well this suits coding agents. If you run more than one agent on a codebase — one refactoring, one writing tests, one drafting content — they can’t safely share a working directory any more than two people can share a keyboard. Give each its own worktree and its own branch, and they work in parallel without trampling each other. You review and merge the branches like any other PRs.

This site was built that way: several agents, each in its own worktree on its own branch, merged into an integration branch once reviewed. The same rules that keep a human sane apply: keep the number of active worktrees small, branch from an up-to-date base, merge little and often.

Gotchas

• A branch can only be checked out in one worktree at a time. That’s a feature — it stops two directories fighting over the same branch.
• Each worktree needs its own dependency install. Fast package managers and a shared cache make this cheap.
• Clean up. git worktree prune removes records of directories you’ve deleted by hand.
• Ignored files such as local env files don’t follow you into a new worktree; copy what you need, deliberately.

Takeaways

• Treat each branch as a separate desk, not a drawer you keep emptying.
• One worktree per PR makes reviews and fixes painless.
• Parallel agents need isolation for the same reasons people do; worktrees are the cheapest way to give it.
• Keep the list short. A worktree list is a WIP limit you can see — see You Can’t Serve Two Masters.

---

Originally written in 2022 → Git Worktree workflow