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 changes, switch branches, fix the bug, switch back, pop the stash, and hope nothing conflicts. Git worktrees eliminate this workflow entirely by letting you check out multiple branches in separate directories — simultaneously. Here’s everything you need to know to start using them in 2026.

What Are Git Worktrees?

A Git worktree is an additional working directory linked to the same repository. Unlike cloning the repo again, worktrees share the same .git metadata, so they take minimal extra disk space and stay perfectly in sync. Every Git repo already has one worktree — your main working directory. The git worktree command lets you add more.

Think of it like having multiple desks in the same office, each with a different document open. You can walk between them freely without ever closing or saving a draft.

Getting Started: Creating Your First Worktree

The basic syntax is straightforward:

# Create a worktree for an existing branch
git worktree add ../hotfix-login hotfix/login-bug

# Create a worktree with a NEW branch
git worktree add -b feature/new-dashboard ../dashboard main

The first command checks out the hotfix/login-bug branch into a sibling directory called hotfix-login. The second creates a new branch feature/new-dashboard based on main and checks it out in ../dashboard.

After running either command, you can cd into that directory and work normally — run builds, tests, editors, everything. It’s a fully functional working directory.

Managing Worktrees

List all your active worktrees:

$ git worktree list
/home/dev/myproject          abc1234 [main]
/home/dev/hotfix-login        def5678 [hotfix/login-bug]
/home/dev/dashboard           ghi9012 [feature/new-dashboard]

When you’re done with a worktree, clean it up:

# Remove the directory first, then prune
rm -rf ../hotfix-login
git worktree prune

# Or in one step (Git 2.17+)
git worktree remove ../hotfix-login

Real-World Use Cases

1. Hotfix While Developing

The classic scenario. You’re building a feature and a critical bug lands:

# You're in ~/project on feature/payments
# Urgent bug reported — create a worktree
git worktree add ../project-hotfix main
cd ../project-hotfix
git checkout -b hotfix/cart-crash

# Fix the bug, commit, push
git add .
git commit -m "fix: prevent cart crash on empty session"
git push origin hotfix/cart-crash

# Go back to your feature — everything is exactly as you left it
cd ~/project

2. Running Tests on Two Branches Simultaneously

Need to compare performance or behavior between branches? Worktrees let you run both at the same time:

git worktree add ../project-v2 feature/v2-refactor

# Terminal 1: ~/project (main)
npm test

# Terminal 2: ../project-v2 (feature/v2-refactor)
npm test

3. Code Review Without Disruption

Review a colleague’s PR without touching your working directory:

git fetch origin
git worktree add ../review-pr-42 origin/feature/user-auth
cd ../review-pr-42
# Browse code, run it, test it
# When done:
git worktree remove ../review-pr-42

Worktrees vs. Other Approaches

Why not just use git stash or clone the repo again? Here’s how they compare:

• git stash — Works for quick switches, but stashes can pile up, conflict on pop, and you can only work on one branch at a time.
• Multiple clones — Each clone duplicates the entire .git directory (which can be gigabytes). Worktrees share it, saving disk space and keeping everything in sync.
• Worktrees — Lightweight, instant, and you can have as many as you need. The only rule: each branch can only be checked out in one worktree at a time.

Advanced Tips

Use a Dedicated Worktree Directory

Instead of scattering worktrees as siblings, organize them:

mkdir -p ~/worktrees/myproject
git worktree add ~/worktrees/myproject/hotfix hotfix/login
git worktree add ~/worktrees/myproject/review origin/feature/auth

Bare Repo + Worktrees Pattern

Power users often combine bare repos with worktrees for the cleanest setup:

# Clone as bare (no working directory)
git clone --bare git@github.com:user/project.git project.git
cd project.git

# Create worktrees for each branch you need
git worktree add ../project-main main
git worktree add ../project-dev develop

This way, there’s no “default” working directory — every branch lives in its own dedicated folder, and the bare repo just holds the metadata.

Lock a Worktree

If a worktree is on an external drive or network mount that isn’t always available, lock it to prevent accidental pruning:

git worktree lock ../external-drive-worktree
git worktree unlock ../external-drive-worktree

Common Gotchas

• Same branch, two worktrees: Git won’t allow it. Each branch can only be checked out in one worktree. If you need the same code in two places, create a new branch from it.
• Submodules: Worktrees and submodules can conflict. Run git submodule update --init in each new worktree.
• IDE config: Each worktree is a separate directory, so your IDE may need separate project settings. Most modern editors (VS Code, JetBrains) handle this gracefully.

Wrapping Up

Git worktrees are one of those features that feel like a superpower once you start using them. They’ve been available since Git 2.5 (2015) but remain surprisingly underused. If you regularly juggle multiple branches — for features, hotfixes, code reviews, or testing — worktrees will save you time and mental overhead every single day.

Start with the basics: next time you need to switch branches, try git worktree add instead of git stash. You’ll never go back.