Why Use Git Worktree? Benefits, Tradeoffs, and When to Skip It

If you have ever watched a senior engineer at the next desk over, you might have noticed they have three or four directories open on the same project. Each one is a different branch. They tab between them as if they were tabs in a browser. That is git worktree in action — and they did not have to convince you to use it because their version of working with Git was just calmer.

This is not a marketing post. It is the version of the worktree pitch you would get over coffee from someone who has both adopted it and regretted parts of it. Stick around for the “when to skip it” section — that is the part most articles leave out.

The Three Real Benefits

1. You stop losing context

The day you decide worktree is permanent is usually the day someone Slacks you asking for an urgent hotfix while you are half-way through a refactor. With one checkout, you either stash and switch (and lose your live editor state), or commit-WIP-and- switch (and pollute the branch). With a worktree, you create a new directory, fix the hotfix there, and your refactor stays exactly as you left it — open files, cursor positions, unsaved buffers in your IDE.

The mental cost of context-switching is the real bottleneck of most developer days. Worktree removes one of its biggest contributors. See the team-hotfix case study for a walkthrough.

2. You can finally run two builds at once

A surprisingly large fraction of “Git is slow” complaints are actually “my build is slow and I cannot afford to checkout”. With a worktree you can leave a long test suite running in one directory while you check out main in another. Two terminals, two builds, zero conflict.

This compounds in monorepos. See our monorepo release case study for a setup running three release branches simultaneously.

3. AI agents stop stepping on each other

This was not a benefit five years ago. Today it is the most common reason people install their first manager. Running Claude Code, Codex, or Cursor on the same files at the same time is a recipe for a three-way merge conflict. Each agent in its own worktree, no conflict — the AI cannot edit what it cannot see. The pattern is documented in parallel AI agents with git worktree.

The Tradeoffs Nobody Mentions

Tradeoff 1: dependencies multiply

Each worktree is a full working directory. That means each one has its own node_modules, its own Python venv, its own Docker volume cache. For a project with 800MB of dependencies, three worktrees cost you 2.4GB of disk before you have written a single line of code.

Workarounds exist (pnpm with shared store, symlinks, lazy installs) but they are not zero-friction. See our node_modules guide for the current best patterns. The honest answer: yes, this is a real cost. Plan for it.

Tradeoff 2: .env and local config drift

Files that are gitignored (.env, .env.local, IDE configs, local-only scripts) exist per worktree, not centrally. Create a new worktree, and it has none of them. The first 10 minutes of every new worktree are spent re-copying these files.

Some teams symlink their env from one canonical location into each worktree. Some use direnv. See our .gitignore and .env files guide for the patterns that work.

Tradeoff 3: cleanup creep

Worktrees are easy to make and easy to forget. After two months of casual use you will likely have 10 directories you cannot remember the purpose of. The right discipline is to run git worktree list every Friday and prune ruthlessly. Some teams bake this into a cron job. None bake it into Git itself, which is the missing feature most worktree managers eventually try to add.

Three Reasons to Skip Worktree

The fact that worktree is built into Git does not mean it fits every project. Three cases where you should not bother:

You only work on one branch at a time

If you finish a feature before starting another, you have no context to preserve. Branches and stash cover your needs. Adding worktrees adds cognitive cost without paying back.

Your repo is huge and disk is precious

A worktree shares the .git object store — so you save the repo's history size. But the checked-out files are duplicated. If you are on a Chromium-style repo with a 20GB checkout, three worktrees is 60GB. Sparse checkout helps; full worktrees on huge repos do not.

Your IDE does not understand worktrees

IDE support varies. Modern VS Code and IntelliJ have first-class support. Xcode, SourceTree, and GitHub Desktop do not — using worktrees on those means dropping to the terminal often enough that it cancels the productivity gain.

Why People Find Worktree Confusing

One of the top-searched phrases in 2026 is “git worktree is confusing”. The confusion is consistent: people expect a worktree to be a kind of branch. It is not. The cleanest reframing is this:

Once that lands, the rest of the model snaps into place. See our full worktree vs branch comparison for the diagrams.

A Few Tips That Speed Up Adoption

• Pick one consistent directory layout and stick to it. Most people end up with ../project-feature-x siblings or a dedicated ~/wt/<project>/<branch> tree. Either works; choose one. Our best practices guide documents both.
• Pair worktree with tmux if you live in the terminal. One worktree per tmux window is the closest thing to a productivity hack worktree alone can give you.
• Delete by Friday rule: any worktree older than a week and not actively committed to gets removed. Run git worktree list and git worktree prune in your weekly review.
• Don't over-tool early. Start with plain CLI. If you cross five active worktrees, install a manager — our roundup has the current picks.

The Honest Recommendation

Try git worktree once with a real task. Pick a side branch, create a worktree for it, do the work, push, remove the worktree. That single round-trip will tell you more than any essay. If it felt smoother than the stash + switch dance, you have your answer. If it felt heavier, also fine — your workflow may not benefit yet.

The day you appreciate it most is the day a teammate asks for an urgent hotfix and you do not have to put anything down to help. That is when worktree pays for itself.

Citations

• git-worktree official documentation — the canonical reference
• Pro Git: Advanced Branching — the chapter that uses worktrees in real workflows