Git Worktrees Changed How I Handle Context Switching

Every developer knows the drill: you’re deep in a feature branch when a bug report lands that needs a quick fix on main. So you stash your changes, switch branches, wait for your editor to re-index, fix the bug, switch back, pop the stash, and hope nothing got corrupted.

Git worktrees eliminate that entire cycle.

What Worktrees Are

A worktree is a separate working directory linked to the same repository. Each worktree checks out a different branch, but they all share the same .git history, remotes, and configuration. No cloning, no duplicate objects.

# Create a worktree for a hotfix
git worktree add ../woolwand-hotfix main

# Now you have two directories:
# ./woolwand          → your feature branch (untouched)
# ./woolwand-hotfix   → main branch, ready to work on

Open each directory in a separate editor window. No stashing. No branch switching. No waiting for rebuilds. Your feature branch stays exactly where you left it.

The Real Cost of Context Switching

The problem with git stash && git checkout isn’t the two seconds those commands take. It’s everything that follows:

• Your editor re-indexes the entire project
• Build tool caches get invalidated
• Dev servers restart and need to recompile
• Your mental model of the code resets — this is the expensive part

Worktrees sidestep all of it. Fix the bug in a separate directory, push it, switch back to your original window. Everything is still warm.

How I Use Them Day to Day

My typical setup:

• Main worktree: whatever feature I’m currently building
• Permanent second worktree: main branch, always clean — used for quick fixes and checking out PRs for review
• Temporary third: spun up on demand for reviewing someone else’s PR or testing a specific branch

# List active worktrees
git worktree list

# Remove one when you're done
git worktree remove ../woolwand-hotfix

# Prune stale worktree references (if you deleted the directory manually)
git worktree prune

A useful pattern: alias worktree creation so it always puts worktrees in a predictable sibling directory. That keeps your filesystem tidy and makes cleanup easy.

The Catches

• One branch per worktree. You can’t have two worktrees checking out the same branch. Each needs a unique branch or a detached HEAD.
• Some tools get confused. Worktrees use a .git file (not a directory) that points to the main repo. Tools that assume .git is always a folder may break, though most modern editors and build tools handle it fine.
• Disk overhead is minimal since worktrees share the object store. You’re only duplicating the working tree files, not the full repo history.

When to Reach for This

If you rarely switch branches mid-task, worktrees won’t change much. But if you regularly juggle feature work, hotfixes, and code reviews — and you’re tired of the stash-switch-rebuild tax — try them. It’s one of those Git features that once adopted, you wonder how you worked without.