Stop Stashing, Start Worktree-ing: A Faster Way to Juggle Git Branches

The problem we all pretend isn't a problem

Be honest. How many times this week did this happen to you?

You're deep in a refactor. Tests are half-green, your IDE has finally finished indexing, and you've got that fragile mental model of the code loaded into your head. Then Teams pings:

Hey, can you take a quick look at my PR? I think something's off in the auth flow.

Or worse:

Prod is breaking on the checkout page. Can you hotfix?

What follows is the same dance we all know:

1. git stash (or panic-commit a "WIP" you'll regret later)
2. git checkout other-branch
3. Wait for the IDE to re-index the entire repo
4. Wait for node_modules / build artifacts / Docker containers to catch up
5. Do the thing
6. Switch back
7. Wait again
8. Try to remember where you were

On a large repo, each round trip easily costs 5–15 minutes of nothing-useful-happening time — not counting the context switch tax in your head, which is the expensive part.

There's a better way, and it's been sitting inside git the entire time.

Meet git worktree

git worktree lets you check out multiple branches at the same time, each in its own folder, all backed by the same repository. No re-cloning. No stashing. No waiting for the IDE to re-index because your main project folder never changed.

Think of it like opening a second tab on the same repo.

# From inside your repo
git worktree add ../myproject-hotfix hotfix/checkout-bug

That's it. You now have a second folder, ../myproject-hotfix, checked out to the hotfix/checkout-bug branch. Your original folder is completely untouched — still on your feature branch, still with your uncommitted changes, still with your IDE happily indexed.

Open the new folder in a second IDE window, fix the bug, push, and close it. Your main work is exactly where you left it.

"Isn't that just cloning the repo twice?"

Fair question. A lot of people's first instinct is to just git clone the repo into a second folder. It works — but it's wasteful:

• Double the disk space. Every clone carries its own full .git history.
• Double the fetches. Pull on one, and the other has no idea.
• Branches don't sync. A local branch you create in clone A is invisible from clone B unless you push it somewhere.
• Credentials, hooks, config — all duplicated.

Worktrees share the single underlying .git directory. One git fetch updates everything. Local branches are visible everywhere. It's the same repo, just checked out in multiple places.

The commands you'll actually use

Ninety percent of your worktree usage will be these four commands.

Create a worktree from an existing branch:

git worktree add ../project-review feature/their-branch

Create a worktree and a brand-new branch off main:

git worktree add ../project-hotfix -b hotfix/login-bug origin/main

List all your active worktrees:

git worktree list

Remove a worktree when you're done:

git worktree remove ../project-hotfix

That's genuinely it. No new mental model, no arcane flags. If you know git checkout, you already understand worktrees.

Where this pays off for us

Think about our actual week-to-week work:

Code reviews. Pulling down a teammate's branch to actually run their code (not just skim the diff on GitHub) becomes zero-cost. Spin up a worktree, run it, kill the worktree. Your own branch never moved.

Hotfixes during feature work. Prod issues don't care that you're mid-refactor. A dedicated hotfix worktree means you can respond in 30 seconds instead of 10 minutes of stash-and-pray.

Long CI cycles. If you're waiting 20–40 minutes for a pipeline on a CI-tuning branch, you can keep a second worktree open on your real feature and stay productive while the build runs. This is the scenario Andrew Lock calls out specifically — he keeps a "permanent" second worktree around just for this.

Comparing two branches side-by-side. Ever wanted to run two versions of the app at the same time to compare behavior? Two worktrees, two terminals, two browser tabs. Done.

Big refactors that take days. Keep the refactor in one worktree and do your regular ticket work in another. They never interfere.

A suggested setup

One tip that makes worktrees much nicer in practice: put your main worktree in a subfolder too, so all worktrees for a repo live under one parent directory. Something like:

~/code/myproject/
    main/         ← your primary worktree (was just "myproject/" before)
    hotfix/       ← temporary, for urgent fixes
    review/       ← temporary, for reviewing others' PRs
    ci-tuning/    ← long-running side branch

Now every worktree for the project is one folder away from the others, and your file explorer stays sane.

The gotchas (small, but know them)

• You can't check out the same branch in two worktrees. Git will refuse. This is a feature — it prevents you from accidentally committing to the same branch from two places.
• Some tooling assumes one folder per repo. Most modern IDEs (VS Code, IntelliJ family, Cursor) handle worktrees fine. If you hit something weird, it's almost always because a tool cached a path.
• node_modules, venv, target/, build caches — these are per-folder. Each worktree needs its own. For most of our projects this is a one-time npm install and you're done. For heavier setups, worth thinking about.
• Don't forget to clean up. git worktree list is your friend. Stale worktrees are harmless but clutter up your disk.

Try it this week

Here's the challenge. Next time one of these happens to you:

• A teammate asks you to review their branch
• You need to compare behavior between two branches
• A hotfix lands while you're mid-feature
• You're waiting on a long CI run

…instead of stashing, try:

git worktree add ../$(basename $PWD)-side <branch-name>

Give it one week. I think most of you will stop going back.

Further reading

• Andrew Lock — Working on two git branches at once with git worktree — the post that convinced a lot of .NET devs to switch.
• Git up! Use worktree to boost efficiency (Medium)
• Official docs — git worktree