Git Worktrees: Work on Multiple Branches Without Stashing

You're mid-refactor with a dozen uncommitted files when a critical bug report comes in. You git stash, switch branches, fix the bug, switch back, git stash pop, and hope nothing conflicts. Most developers do this dance weekly without knowing there's a way to skip it entirely: git worktrees let you check out multiple branches into separate directories from the same repository, at the same time.

The problem worktrees solve

A normal git checkout only lets one branch be active per repository directory. Worktrees remove that restriction — one .git directory, multiple working directories, each on its own branch, fully independent.

# You're in ~/projects/myapp on branch feature/big-refactor
git worktree add ../myapp-hotfix main
cd ../myapp-hotfix
# This is a completely separate working directory, on main,
# with your original directory's uncommitted changes untouched

Fix the bug, commit, push, and switch back to your original directory — your refactor's uncommitted state is exactly as you left it. No stash, no risk of stash conflicts, no mental overhead of "what was in my stash again?"

Basic commands

# Add a worktree for an existing branch
git worktree add ../myapp-review origin/pr-123

# Add a worktree with a new branch
git worktree add -b feature/new-thing ../myapp-new-thing

# List all worktrees
git worktree list

# Remove a worktree when you're done
git worktree remove ../myapp-hotfix

Each worktree has its own working directory and index, but they all share the same object database, so you're not duplicating the entire repo's history on disk — just the checked-out files.

A real workflow: reviewing PRs without disrupting your work

git worktree add ../myapp-pr-456 origin/feature-branch
cd ../myapp-pr-456
npm install
npm run dev
# Review, test, leave comments — your main working directory
# never left the branch you were actually working on
git worktree remove ../myapp-pr-456

This is dramatically better than stashing your work, checking out the PR branch, testing it, then switching back — especially when the PR branch needs a different node_modules state or a running dev server you don't want colliding with your main one.

Running tests against two versions simultaneously

git worktree add ../myapp-before v1.2.0
git worktree add ../myapp-after main
# Run the same benchmark script against both directories,
# compare output directly — no checkout back-and-forth

Common mistakes

• Trying to check out the same branch in two worktrees at once — git blocks this, since it doesn't make sense to have one branch checked out in two places simultaneously.
• Forgetting to git worktree remove finished worktrees, leaving stale directories that clutter git worktree list and confuse teammates looking at your disk layout.
• Deleting a worktree directory with rm -rf instead of git worktree remove — this leaves dangling metadata in .git/worktrees that git still thinks is active. Run git worktree prune to clean that up if it happens.
• Assuming worktrees duplicate disk usage for the full repo history — they don't; only the checked-out working files are duplicated, not the .git object database.

What I'd actually use

Worktrees for anything that used to trigger a stash: urgent hotfixes mid-feature, reviewing a colleague's PR locally, or running two versions side by side for a bisect-style comparison. I keep a dedicated ../worktrees/ directory next to my main clone so they don't clutter the same parent folder as unrelated projects.

Next steps

Next time you reach for git stash because something urgent interrupted your work, try git worktree add instead. Once you've done it twice, stashing for this reason stops making sense.