Git worktree — Stop Stashing, Start Working in Parallel

Published: (January 11, 2026 at 07:35 AM EST)
4 min read
Source: Dev.to

Source: Dev.to

Introduction: the pain of branch switching 😤

If you’ve worked with Git long enough, you’ve lived this moment:

You’re deep into a feature. Files are half‑written. Tests are failing (on purpose).

Then suddenly:

  • “Hey, can you quickly fix this hotfix on main?”
  • “Can you review this PR locally?”

So you do the dance:

git status
git stash
git checkout main

Later…

git checkout feature/my-work
git stash pop
# 💥 conflicts

Context lost. Flow broken. Confidence shaken.

Git has had a solution for this for years — and many developers still don’t use it: git worktree.

What is git worktree? 🌳

git worktree lets you check out multiple branches of the same repository at the same time, each in its own directory.

Key idea

  • One Git repository
  • Multiple working directories
  • Each directory has its own checked‑out branch

You’re not cloning the repo again. You’re not copying history. You’re just creating another view of the same repository.

Parallel checkouts without the pain.

How git worktree works (conceptually) 🧠

A normal Git repo:

  • One .git directory (history, objects, refs)
  • One working directory (your files)

With worktrees:

  • Still one .git
  • Multiple working directories

Each worktree:

  • Is on a different branch
  • Has its own files
  • Is completely isolated from the others

What’s shared

  • Git history, commits, objects

What’s isolated

  • Checked‑out branch
  • Working files
  • Uncommitted changes

Multiple terminals, multiple folders, same repo.

git worktree vs traditional branch switching ⚖️

Traditional workflow

  • One working directory
  • One branch at a time
  • Frequent stashing
  • Easy to lose context

With git worktree

  • No stashing
  • No dirty working‑tree problems
  • No accidental changes on the wrong branch
  • True parallel work

In short: branch switching → sequential work; worktrees → parallel work.

Practical use cases (real workflows) 🚀

Feature development + hotfix 🚑

You’re working on feature/auth and a production bug appears on main.

git worktree add ../repo-hotfix main

Now you have:

repo/           → feature/auth
repo-hotfix/    → main

Fix the bug, commit, push — without touching your feature work.

Reviewing a PR locally 🔍

Check a teammate’s branch:

git worktree add ../repo-pr-123 pr/some-feature

Open it in your editor, run tests, explore freely. Your main work stays intact.

Experiments and spikes 🧪

Trying a risky refactor?

git worktree add ../repo-experiment experiment/refactor-auth

If it works → keep it. If it doesn’t → delete the worktree. Zero fear. Zero mess.

Release or QA validation 🧪

Keep a stable branch checked out:

git worktree add ../repo-release release/1.4

Run builds, verify fixes, validate QA while continuing normal feature work elsewhere.

Step-by-step: using git worktree 🛠️

Create a new worktree

From your main repo:

git worktree add ../my-repo-hotfix main
  • Creates a new directory
  • Checks out main there
  • Links it to the same Git repo

Create a worktree with a new branch

git worktree add -b feature/payments ../my-repo-payments

Perfect for starting new work.

List all worktrees

git worktree list

Example output:

/path/repo              abc123  feature/auth
/path/repo-hotfix       def456  main
/path/repo-experiment   ghi789  experiment/refactor

Work normally

Inside a worktree you can run the usual commands:

  • git status
  • git commit
  • git push

Everything behaves exactly like a normal repo.

Remove a worktree (cleanup 🧹)

When you’re done:

git worktree remove ../my-repo-hotfix
  • Cleans Git metadata
  • Safely removes the worktree

⚠️ Avoid deleting the folder manually; always use git worktree remove.

Common pitfalls & gotchas ⚠️

  • One branch = one worktree – you can’t check out the same branch twice.
  • Always use git worktree remove instead of deleting folders manually.
  • Shared files such as .env, node_modules, or build outputs may need isolation (e.g., .env.local or per‑worktree configs).
  • Your IDE might open multiple projects; this is usually a feature, not a bug.

When git worktree shines — and when it doesn’t ✨

It shines when

  • You juggle features and hotfixes
  • You’re frequently interrupted
  • You work on large repos
  • You want clean mental separation

It may not be worth it when

  • The repo is tiny
  • You only do one task at a time
  • You’re still learning Git fundamentals

Conclusion & takeaways 🎯

git worktree isn’t a niche feature; it’s a productivity multiplier.

Key takeaways

  • Stop stashing just to switch context
  • Work on multiple branches at the same time
  • Keep your flow, keep your sanity
  • Enable clean, explicit, parallel work

Once you try it, going back to constant stashing feels… painful. Give git worktree a try on your next interruption and see how it changes your workflow.

Back to Blog

Related posts

Read more »