Git Worktree: Work on Multiple Branches Simultaneously Without Stashing or Cloning – ITFROMZERO

Table of Contents

A familiar problem: interrupted mid-task by something urgent

You’re coding a new feature on the feature/payment branch, halfway through your changes, when your manager messages: “Urgent — a customer reported a production bug, fix it now.” At this point you have a few options:

Make a throwaway commit (pollutes your history)
Use git stash (then forget about it, and hunting it down later is a headache)
Clone the entire repo into another directory (wastes disk space, you have to set up node_modules all over again…)

I’ve been through all three. Once I stashed in a panic, then accidentally did a git push --force on the wrong branch — lost an entire morning of work. After that I became extremely careful with force pushes, and I also started looking for a better way to handle this kind of context-switching. If you’re not already familiar with git stash and when it actually helps, it’s worth understanding its limitations before reaching for Worktree.

That’s when I discovered Git Worktree.

What is Git Worktree?

A worktree (or working tree) is the directory containing the files you’re actively working on — the folder you open in VS Code or your terminal every day. Normally, a repository has just one working tree.

Git Worktree lets you attach additional working trees to the same repository, with each tree checking out a different branch. They all share the same .git folder — shared history, shared object database — but the working files are completely separate.

Think of it like opening the same Google Doc in two browser tabs, each displaying a different version of the document — but the underlying data is still one and the same.

Quick comparison with other approaches

git stash: Works for temporary saves, but you have to switch branches and lose your context. On large projects, stashing a dozen times starts getting confusing fast.
Clone the repo again: Doubles your disk usage — if your project has a 500MB node_modules, that doubles immediately. And you still have to reinstall all dependencies from scratch.
Git Worktree: Separate working directories, separate branches, but sharing the same .git — fast, lightweight, no duplication.

Hands-on: how to use Git Worktree

1. View your current worktrees

Every repository already has at least one worktree — the directory you’re currently working in. Check it with:

git worktree list

The output will look something like this:

/home/user/myproject  abc1234 [main]

2. Create a new worktree for a hotfix branch

Back to the original scenario: you’re on feature/payment and need to fix a bug on main. Instead of stashing, create a new worktree:

# Create the ../myproject-hotfix directory, checking out the hotfix/critical-bug branch
git worktree add ../myproject-hotfix hotfix/critical-bug

If the branch doesn’t exist yet, create it on the fly with the -b flag:

git worktree add -b hotfix/critical-bug ../myproject-hotfix main

This creates a new branch hotfix/critical-bug from main and checks it out into the ../myproject-hotfix directory.

Now open a second terminal, cd ../myproject-hotfix, and work freely — your original terminal stays right where it was on feature/payment, completely undisturbed.

3. Clean up after the hotfix

Once you’ve committed and pushed the hotfix, remove the extra worktree:

# Remove the worktree (the directory will be deleted along with it)
git worktree remove ../myproject-hotfix

# Or force-remove if there are uncommitted files you want to discard:
git worktree remove --force ../myproject-hotfix

Then clean up any leftover metadata (good to run periodically):

git worktree prune

4. Real-world workflow: reviewing a PR while still coding

This is the use case I reach for most often. A teammate submits a PR that needs review, but I’m mid-task. Instead of stashing or making a throwaway commit:

# Create a worktree to review PR #42
git worktree add ../review-pr-42 origin/feature/teammate-branch

# Open that directory in another editor or terminal
code ../review-pr-42

Once the review is done, close the editor and remove the worktree:

git worktree remove ../review-pr-42

5. Using a bare repo — a more professional setup

If you regularly work across multiple branches, you can set things up with a bare repo — clone without a default working tree, then create worktrees for each branch you need:

# Clone as bare
git clone --bare https://github.com/user/myproject.git myproject.git
cd myproject.git

# Create a worktree for each branch
git worktree add ../myproject-main main
git worktree add ../myproject-feature feature/payment
git worktree add ../myproject-staging staging

The result is a structure like this:

myproject.git/          ← .git folder (bare)
myproject-main/         ← main branch
myproject-feature/      ← feature/payment branch
myproject-staging/      ← staging branch

Each directory is an independent working tree. Working in one terminal has zero effect on any other.

A few things to keep in mind

A branch can only be checked out in one worktree at a time: if you try to check out main in two worktrees simultaneously, Git will throw an error. This is intentional — it prevents conflicts when two processes write to the same branch at once.
Node modules and build artifacts are not shared: each worktree is its own directory, so you’ll need to run npm install or rebuild separately for each one if needed.
The .git entry in a linked worktree is a file, not a folder: it contains a path pointing back to the main .git directory — this is how Git tracks the relationship between worktrees.

Conclusion

What makes Git Worktree great is that it solves a problem every developer has faced: getting pulled away from work mid-task. Instead of making throwaway commits, losing track of stashes, or cloning a heavy repo just to have a second working directory — one command gets you a clean, isolated workspace on the right branch.

In practice, I use it most for two things: urgent hotfixes and PR reviews. Both take only seconds to set up and don’t break whatever context I was already in. Try it once and you’ll find it hard to go back to the old stash-and-hunt approach.

If your team uses Git daily and hasn’t discovered Worktree yet, this is the most valuable feature to learn this year — small, requires no extra installation, but saves a surprising amount of time and frustration. Pair it with a solid Git workflow for your team and you’ll spend far less time context-switching and far more time shipping.