Git Worktrees: The Feature That Will Change How You Work

You're deep in a feature branch, files changed everywhere, when a teammate asks you to review their PR. What do you do? Stash your changes, switch branches, review, switch back, pop the stash, hope nothing conflicts? Or worse — clone the repo again into a separate directory?

There's a better way. Git worktrees let you check out multiple branches simultaneously, each in its own directory, sharing a single .git repository. It's one of Git's most powerful and least known features.

How Worktrees Work

A worktree is an additional working directory linked to your existing repository. Each worktree has its own checked-out branch, its own index (staging area), and its own working files — but they all share the same Git history, objects, and refs. No redundant clones, no duplicated data.

# You're on feature/dashboard, deep in work
git branch
# * feature/dashboard

# Create a worktree for reviewing a teammate's PR
git worktree add ../review-auth feature/new-auth-flow

# Now you have two directories:
# ~/projects/my-app/           → feature/dashboard (your work, untouched)
# ~/projects/review-auth/      → feature/new-auth-flow (ready to review)

# Review the code, run tests, leave comments
cd ../review-auth
npm install  # only needed if dependencies changed
npm test

# Done reviewing? Remove the worktree
cd ../my-app
git worktree remove ../review-auth

Your feature branch is completely untouched. No stashing, no switching, no risk of losing work. The review happens in a separate directory with its own node_modules and build artifacts.

The Hotfix Workflow

Worktrees really shine for emergency fixes. Production is down, you need to patch main, but your current branch has three days of uncommitted experiments:

# Create a hotfix worktree from main
git worktree add ../hotfix-critical main

cd ../hotfix-critical
git checkout -b hotfix/fix-auth-crash

# Make the fix, test it, push it
# ... edit files ...
npm test
git add -A && git commit -m "fix: prevent auth crash on expired tokens"
git push -u origin hotfix/fix-auth-crash

# Create PR, get it merged, clean up
cd ../my-app
git worktree remove ../hotfix-critical

The entire hotfix happened without touching your feature branch. No stash conflicts, no accidentally committing debug code to the wrong branch, no rebuilding node_modules after switching back.

Practical Tips

Naming convention. I keep worktrees in sibling directories named by purpose: ../review-*, ../hotfix-*, ../experiment-*. This keeps them organized and makes cleanup obvious.

Shared node_modules. Each worktree gets its own node_modules by default. If dependencies are identical across branches, you can symlink to save space, but in practice the isolation is worth the disk cost.

IDE support. VS Code handles worktrees well — just open the worktree directory as a separate window. Your main window stays focused on your primary branch.

List and clean. Run git worktree list to see all active worktrees and git worktree prune to clean up stale references from deleted directories.

When Not to Use Worktrees

If you're already disciplined about small, frequent commits and your branch switches are fast, worktrees add complexity you don't need. They're also overkill if your project has minimal build artifacts — the cost of switching branches is low when there's nothing to rebuild.

But for frontend projects with heavy node_modules, long build times, and frequent context switches between branches, worktrees are transformative. Try it once for a code review, and you'll never go back to the stash-switch-review-switch-pop dance.