If you’ve ever been deep in a feature branch and needed to urgently fix a bug on main, you know the pain: stash your work, switch branches, fix the bug, switch back, pop the stash, and pray nothing conflicts. Git worktrees eliminate this entire workflow by letting you check out multiple branches simultaneously in separate directories. Here’s everything you need to master this underused Git superpower in 2026.

What Are Git Worktrees?

A Git worktree is an additional working directory linked to the same repository. Each worktree has its own checked-out branch, its own staging area, and its own working files — but they all share the same .git history and objects. Think of it as having multiple clones, but without duplicating the entire repository.

Why Worktrees Beat the Stash-and-Switch Workflow

• Zero context switching cost: No stashing, no lost uncommitted changes, no accidental stash pops on the wrong branch.
• Parallel builds: Run your dev server on the feature branch in one terminal while building the hotfix in another.
• Disk efficient: Unlike cloning the repo twice, worktrees share Git objects — saving gigabytes on large monorepos.
• IDE friendly: Open each worktree in a separate VS Code window with its own workspace settings.

Getting Started: Your First Worktree

Let’s say you’re on feature/dashboard and need to hotfix main:

# Create a new worktree for main in a sibling directory
git worktree add ../myproject-main main

# That's it! Now you have:
# ~/projects/myproject/          → feature/dashboard
# ~/projects/myproject-main/     → main

Navigate to ../myproject-main, make your fix, commit, push — all without touching your feature branch working directory.

Essential Worktree Commands

# List all worktrees
git worktree list
# Output:
# /home/dev/myproject             abc1234 [feature/dashboard]
# /home/dev/myproject-main        def5678 [main]

# Create worktree with a new branch
git worktree add ../myproject-experiment -b experiment/new-api

# Remove a worktree when done
git worktree remove ../myproject-main

# Clean up stale worktree references
git worktree prune

Real-World Workflow: Code Review With Worktrees

One of the best use cases is reviewing pull requests while keeping your own work untouched:

# Create a worktree to review a colleague's PR
git fetch origin pull/42/head:pr-42
git worktree add ../review-pr-42 pr-42

# Open it in VS Code
code ../review-pr-42

# Run tests in the PR branch
cd ../review-pr-42
npm install && npm test

# When done reviewing, clean up
cd ../myproject
git worktree remove ../review-pr-42
git branch -D pr-42

Advanced: Worktrees in CI/CD Pipelines

Worktrees can speed up CI pipelines that need to compare builds across branches:

#!/bin/bash
# compare-bundle-size.sh — CI script to compare bundle sizes

# Current branch bundle
npm run build
CURRENT_SIZE=$(du -sb dist/ | cut -f1)

# Main branch bundle via worktree
git worktree add /tmp/main-build main
cd /tmp/main-build
npm ci && npm run build
MAIN_SIZE=$(du -sb dist/ | cut -f1)

# Calculate difference
DIFF=$((CURRENT_SIZE - MAIN_SIZE))
echo "Bundle size delta: ${DIFF} bytes"

# Cleanup
cd -
git worktree remove /tmp/main-build

# Fail if bundle grew by more than 50KB
if [ $DIFF -gt 51200 ]; then
  echo "ERROR: Bundle size increased by more than 50KB"
  exit 1
fi

Worktree Rules and Gotchas

Before you go worktree-crazy, keep these constraints in mind:

• One branch per worktree: You cannot have the same branch checked out in two worktrees simultaneously. Git enforces this to prevent conflicting writes.
• Shared refs: Since all worktrees share the same .git directory, operations like git gc and git fetch affect all of them.
• Submodules need care: Each worktree needs its own submodule initialization. Run git submodule update --init in each new worktree.
• Hooks are shared: Git hooks in .git/hooks run for all worktrees. If your pre-commit hook assumes a specific directory structure, it may break in worktree paths.

Pro Tips for Daily Use

Here are patterns that make worktrees even more powerful:

# Alias for quick worktree creation
git config --global alias.wt 'worktree add'
git config --global alias.wtl 'worktree list'
git config --global alias.wtr 'worktree remove'

# Now you can do:
git wt ../hotfix main
# ... fix, commit, push ...
git wtr ../hotfix

For monorepo users, combine worktrees with sparse checkout for lightning-fast partial checkouts:

# Sparse worktree — only check out the 'packages/api' directory
git worktree add --no-checkout ../api-only main
cd ../api-only
git sparse-checkout set packages/api
git checkout

When NOT to Use Worktrees

Worktrees aren’t always the right tool:

• Quick one-file fixes: If you just need to edit one file on another branch, git stash is simpler.
• Long-lived parallel development: If two branches diverge significantly over weeks, separate clones give better isolation.
• Shared network drives: Worktrees with paths on NFS or SMB mounts can cause locking issues.

Wrapping Up

Git worktrees have been available since Git 2.5 (2015), yet most developers still don’t use them. In 2026, with increasingly complex branching strategies and monorepo architectures, worktrees are more relevant than ever. Start with the simple hotfix workflow, graduate to PR reviews, and before long you’ll wonder how you ever lived without them.

The key takeaway: stop stashing and start branching in parallel. Your future self — mid-way through a feature, interrupted by an urgent Slack message — will thank you.