Home DevOps Git Worktree — Simultaneous Branches Without Stashing Chaos
Advanced 3 min · July 07, 2026

Git Worktree — Simultaneous Branches Without Stashing Chaos

Stop stashing and switching.

N
Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Everything here is grounded in real deployments.

Follow
Production
production tested
July 07, 2026
last updated
214
articles · all by Naren
Before you start⏱ 15 min
  • Deep devops experience in a production environment
  • Familiarity with debugging, profiling, and performance analysis
  • Understanding of distributed systems and failure modes
 ● Production Incident
Quick Answer

git worktree add ../project-hotfix hotfix/bug creates a new directory with the hotfix branch checked out. git worktree list shows all worktrees. git worktree remove ../project-hotfix cleans up.

✦ Definition~90s read
What is Git Worktree?

git worktree allows you to check out multiple branches simultaneously in separate working directories, all sharing the same .git folder. Each worktree is an independent working copy linked to the same repository.

Imagine having the same book open to two different chapters at the same time on your desk.
Plain-English First

Imagine having the same book open to two different chapters at the same time on your desk. git worktree is like having two physical copies of the repo on your hard drive, but they share the same bookmark file (.git). You can work on a feature in one window and review a PR in another, without stashing or committing half-done work.

The standard Git workflow forces you to stash or commit before switching branches. git worktree removes this constraint entirely. Each worktree is a full working directory linked to the same .git database. You can build and test both branches simultaneously, switch between them instantly, and never lose context. The one constraint: a branch can only be checked out in one worktree at a time. This guide covers setup, the constraint that caught a team mid-deploy, and how to integrate worktrees into your daily workflow.

Setting Up and Managing Worktrees

git worktree add <path> <branch> creates a new worktree. If <branch> doesn't exist, add -b to create it. Each worktree has its own working directory, index, and HEAD. They share objects, refs, and config from the parent .git.

git worktree list shows all worktrees with their paths, branches, and commit SHAs. git worktree remove <path> (or git worktree prune) cleans up. Deleting the worktree directory manually requires git worktree prune to clean the metadata.

The key constraint: you cannot check out the same branch in two worktrees. If you try, Git rejects with 'fatal: '<branch>' is already checked out at '<other-path>''.

01_worktree_setup.shBASH
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Add a worktree for a hotfix
git worktree add ../hotfix-fix -b hotfix/login-error
cd ../hotfix-fix
echo 'Fix login error' >> fix.txt
git add . && git commit -m 'fix: login validation'

# Meanwhile, the original repo is untouched
cd ../original-repo
git status  # clean, still on your feature branch

# List all worktrees
git worktree list

# When done, clean up
rm -rf ../hotfix-fix
git worktree prune
git worktree list
Output
/path/to/original-repo a1b2c3d [feature/dashboard]
/path/to/hotfix-fix d4e5f6g [hotfix/login-error]
Never Delete a Worktree Directory Without Pruning
If you rm -rf a worktree directory without git worktree remove, the .git metadata remains. Future git worktree list shows a stale entry. Run git worktree prune to clean stale records. The worktree lock on the branch persists until you prune.
Production Insight
Worktrees are ideal for monorepos with long build times. Keep three worktrees: one for daily feature work, one for code review (PR checkout), and one for hotfixes. This eliminates stash overhead entirely. CI/CD scripts should always run git worktree prune before deploy to avoid stale lock conflicts.
Key Takeaway
git worktree checks out multiple branches simultaneously in separate directories. Branches are locked to one worktree at a time. Always prune stale worktrees. Use worktrees to eliminate stash-based context switching.
● Production incidentPOST-MORTEMseverity: high

The Deploy That Failed Because a Branch Was Locked

Symptom
A CI/CD pipeline failed because a branch was checked out in a developer's worktree. The deploy script couldn't fast-forward the remote branch. The team lost 40 minutes debugging before finding the worktree lock.
Assumption
The CI failure seemed random — 'refusing to fetch into checked out branch'. The team assumed a server-side issue or a stale lock file.
Root cause
1. A developer used git worktree add ../deploy-prep main to prepare a deployment. 2. They forgot to remove the worktree after finishing. 3. The branch 'main' was locked by the worktree — Git prevents writes to a branch that's checked out anywhere. 4. The CI pipeline's git fetch failed because it couldn't update the remote-tracking ref for main. 5. The error message ('refusing to fetch into checked out branch') was confusing because main wasn't checked out in the CI runner — it was checked out in the developer's worktree on a different machine.
Fix
1. Found the locked branch via git worktree list on the developer's machine. 2. The worktree was stale (the directory had been deleted but Git didn't know). 3. Ran git worktree prune to remove stale worktree records. 4. Re-ran the CI pipeline successfully. 5. Added a pre-deploy CI check: git worktree list should show only the CI runner's worktree.
Key lesson
  • Worktrees lock branches.
  • A branch can only be checked out in ONE worktree at a time.
  • Always run git worktree prune regularly and clean up worktrees when done.
  • CI pipelines should check for stale locks before deploying.
Production debug guideUse this when production is on fire3 entries
Symptom · 01
Review a PR while keeping current work intact
Fix
Run git worktree add ../review-branch <branch-name> — creates a new directory with the PR branch
Symptom · 02
Work on a hotfix without losing feature work
Fix
Run git worktree add ../hotfix -b hotfix/critical — starts a new branch in a separate directory
Symptom · 03
Clean up old worktrees
Fix
Run git worktree list then git worktree remove <path> for each one you don't need

Key takeaways

1
Worktrees share .git but have independent working directories
2
A branch can only be checked out in ONE worktree at a time
3
Always prune stale worktrees with git worktree prune
4
Ideal for monorepo developers needing multiple branches simultaneously
N
Naren Founder & Principal Engineer

20+ years shipping production infrastructure and CI/CD at scale. Everything here is grounded in real deployments.

Follow
Verified
production tested
July 07, 2026
last updated
214
articles · all by Naren
🔥

That's Git. Mark it forged?

3 min read · try the examples if you haven't

Previous
Git Blame: Find Who Changed What and When
29 / 47 · Git
Next
Git Reflog: Recover Lost Commits and Branches