A Git worktree is a second working directory attached to the same repository, with its own checked-out branch, its own file state, and its own index — while sharing one underlying .git history with every other worktree pointed at that repository. Instead of stashing uncommitted changes, checking out a different branch, doing the thing, checking back out, and unstashing, you create a worktree for the second branch and work in it directly, in a separate folder, at the same time. Nothing about your original working directory changes. This turns "I need to quickly look at another branch" from a multi-step, easy-to-mess-up sequence into cd into a different folder.
What changed in 2026
- Editor and IDE support caught up. VS Code, JetBrains IDEs, and most terminal-based Git tooling now recognize worktrees natively, showing the correct branch and status per worktree rather than treating them as unrelated folders.
- AI coding agents made parallel worktrees more common, since running an agent against one branch while continuing to work in another became a practical way to avoid blocking on long agent tasks.
- Package manager and build tool guidance around worktrees matured, with clearer conventions for keeping dependency installs and caches separate per worktree instead of colliding.
git worktree performance improved in recent Git releases, particularly for repositories with large numbers of worktrees or very large histories.
The core commands
# Create a new worktree for an existing branch, in a sibling directory
git worktree add ../myapp-hotfix hotfix/payment-bug
# Create a new worktree AND a new branch at the same time
git worktree add -b feature/new-search ../myapp-search
# List every worktree attached to this repository
git worktree list
# Remove a worktree once you're done with it
git worktree remove ../myapp-hotfix
# Clean up references to worktrees whose directories were deleted manually
git worktree prune
Each worktree checks out a different branch of the same repository — Git enforces that a branch can only be checked out in one worktree at a time, which prevents you from accidentally editing the same branch in two places and losing track of which one is current.
When a worktree beats the alternative
| Situation |
Without worktrees |
With worktrees |
| Urgent hotfix mid-feature |
Stash feature work, switch branch, fix, switch back, unstash |
New worktree, fix directly, remove worktree when done |
| Reviewing a teammate's PR |
Stash or commit work-in-progress just to check it out |
Second worktree checks out the PR branch, original directory untouched |
| Running a long test suite on main while coding a feature |
Can't do both in one directory at once |
One worktree runs tests on main, another has the feature checked out |
| Comparing behavior across two branches |
Two full clones, doubling disk space and remote setup |
Two worktrees, one shared .git, far less disk overhead |
A second full clone works too, but duplicates the entire object database on disk and needs its own remote configuration. A worktree shares history with the original clone, so it is lighter weight and stays in sync without a separate fetch.
Common mistakes
Expecting node_modules or build artifacts to carry over. Worktrees share Git history, not the filesystem state outside of it — each one needs its own dependency install and will rebuild its own artifacts.
Trying to check out the same branch in two worktrees. Git blocks this deliberately, since editing the same branch in two places at once is exactly the confusion worktrees are meant to prevent.
Letting worktrees accumulate without cleanup. A worktree for every branch you've ever glanced at clutters git worktree list and can leave stale directories around long after the branch was merged or deleted.
Deleting a worktree's directory manually instead of using git worktree remove. Git still tracks the worktree internally until you run git worktree prune or the proper remove command, which can cause confusing errors later.
FAQ
Do worktrees work with a bare repository?
Yes — worktrees are commonly used with a bare clone as the central .git store, with every actual checkout living in its own worktree directory rather than one of them being the "main" working copy.
Can I use worktrees with Git submodules?
Yes, though older Git versions had rough edges here; recent Git releases handle submodules inside worktrees reliably.
How is this different from just cloning the repo twice?
A second clone duplicates the full object database and needs its own remote tracking setup. A worktree shares the same underlying repository, so disk usage is far lower and both stay implicitly in sync.
Does each worktree need its own CI or build config?
No, they use the same repository configuration — but local, uncommitted state like environment files, build caches, and installed dependencies is per-worktree and needs to be set up in each one separately.
Where to go next
See feature branch vs trunk-based development for 2026 for the branching models worktrees make easier to work with day to day, and feature flag rollout strategy for 2026 for how trunk-based teams handle unfinished work without long-lived branches at all.