Git Worktrees: Parallel Development Without the Context Switching

August 6, 2026 · 8 min read

If you've ever needed to jump between branches mid-task — fixing a hotfix on main while a feature branch has uncommitted changes — you know the pain. git stash, git checkout, conflicts, lost context. Git worktrees solve this cleanly by letting you check out multiple branches into separate directories, all sharing the same repository.

What Is a Git Worktree?

A worktree is an additional working directory linked to your main repository. Each worktree has its own checked-out files, staging area, and working tree, but they all share the same .git objects database. This means:

No duplicate clones eating disk space
Commits in one worktree are instantly visible in others
You can work on multiple branches simultaneously

Creating Your First Worktree

The basic syntax is straightforward:

# From your repo root
git worktree add ../hotfix-branch hotfix/urgent-fix

# Or create a new branch directly
git worktree add -b feature/new-api ../work-new-api main

This creates a new directory alongside your main repo. You can now cd into it and work independently:

cd ../hotfix-branch
# You're now on hotfix/urgent-fix
# Edit, commit, push — all independent of your main worktree

Real-World DevOps Workflows

1. Hotfix While Feature Work Is In Progress

The most common scenario. You're deep in a feature branch with uncommitted work, and production is on fire:

# From your feature work directory
git worktree add ../hotfix ../main
cd ../hotfix
git pull origin main
# Fix, test, commit, push
git push origin main
cd ../my-feature-branch
# Your feature work is untouched

2. Review PRs Without Stashing

Need to review a teammate's pull request while keeping your work intact?

git fetch origin
git worktree add ../pr-review origin/teammate-feature
cd ../pr-review
# Review, test, leave comments
cd ../my-work
# Back to where you were

3. CI/CD Pipeline Testing

When testing pipeline changes, you often need to compare behavior between branches:

# Two worktrees for A/B testing pipeline configs
git worktree add ../pipeline-v1 release/v1
git worktree add ../pipeline-v2 release/v2

# Run the same test script in each
cd ../pipeline-v1 && ./ci-test.sh
cd ../pipeline-v2 && ./ci-test.sh

Managing Worktrees

List all active worktrees:

git worktree list
# /home/user/my-repo              abc1234 [main]
# /home/user/hotfix               def5678 [hotfix/urgent-fix]
# /home/user/pr-review            ghi9012 [detached HEAD]

Remove a worktree when done:

git worktree remove ../hotfix
# Or if it has uncommitted changes:
git worktree remove --force ../hotfix

Prune stale references to deleted directories:

git worktree prune

Worktree Pitfalls to Avoid

Same branch, two worktrees: Git won't let you check out the same branch in two worktrees. Create a new branch in one of them instead.
Submodules: Worktrees with submodules can be tricky. Run git submodule update --init in each new worktree.
Relative paths in scripts: If your scripts assume .git is in the current directory, they may break in a worktree. Use git rev-parse --git-dir to find the actual git directory.
Orphaned worktrees: If you manually delete a worktree directory, run git worktree prune to clean up the reference.

Worktrees vs. Clones

You might wonder: why not just clone the repo twice? Here's the comparison:

Disk space: Worktrees share object storage. Two clones double your disk usage for a large repo.
Speed: Creating a worktree is nearly instant. Cloning downloads everything again.
Consistency: Worktree commits are immediately visible to each other. Separate clones need a push/pull cycle.
Stashes: Worktrees share the stash reflog, which can be confusing if both try to use git stash.

💡 Pro Tip: Use a naming convention for worktree directories. A common pattern is ../.worktrees/feature-name to keep them organized and out of the way.

Aliasing for Productivity

Add these to your ~/.gitconfig for faster workflow:

[alias]
    wt = worktree
    wta = worktree add
    wtl = worktree list
    wtr = worktree remove
    wtp = worktree prune

Now you can use shorthand:

git wta ../hotfix hotfix/fix
git wtl
git wtr ../hotfix

Conclusion

Git worktrees are one of those features that, once you start using them, you wonder how you ever lived without. They eliminate the friction of branch switching, make code review painless, and let you maintain multiple contexts without mental overhead. For DevOps engineers juggling production fixes, feature development, and CI/CD experiments simultaneously, worktrees are a genuine productivity multiplier.

Start with one worktree for your next hotfix. You'll never go back to git stash gymnastics.