Skip to main content
Mohammad Shehadeh — home (MSH monogram, letter M filled with the Palestinian flag)

Git Worktrees: Work on Multiple Branches at Once

Published on
4 min read

You're deep into a feature. The dev server is running and your editor is set up just right. Then a message lands: production is down, fix it now.

So you stash your work, switch branches, and wait for everything to reload. Twenty minutes later the fix is out, but now you have to figure out where you were.

Git worktrees skip all of that.

One Repo, Many Folders

A Git repo normally has one working folder and one branch at a time. Switching branches rewrites the files in place, so everything resets.

A worktree changes that. One repo can have many folders open at once, each on its own branch. Same history and commits, but separate files you can edit side by side.

It's like having two desks for the same project. Each desk has its own papers, but they share one filing cabinet.

You could get the same side-by-side setup by cloning the repo two, three, or four times, one clone per branch. A worktree gives you that without the copies: the folders share one .git instead of duplicating the whole history each time.

The Key Idea

git switch swaps the branch in one folder. git worktree gives each branch its own folder, so you never switch at all.

Create a Worktree

Use git worktree add with a path and a branch:

terminal
1# Put an existing branch in a folder next to your project
2git worktree add ../app-hotfix hotfix

This makes a new folder with the hotfix branch in it. Your first folder stays exactly as it was.

Want a new branch? Add -b:

terminal
1# Make a new branch "hotfix" off main, in its own folder
2git worktree add -b hotfix ../app-hotfix main

Now cd ../app-hotfix, fix the bug, and push. Your feature work waits in the other folder, untouched.

Why It's Worth It

Here's that hotfix, the worktree way:

terminal
1# You're in ~/code/app, mid-feature. A hotfix lands.
2git worktree add -b hotfix ../app-hotfix main
3
4cd ../app-hotfix
5# ...fix, commit, push, open the PR...
6
7# Done. Go back to where you were:
8cd ../app
9# Your branch, your files, your running server: all as you left them.

No stash. No "WIP" commit. No setup to redo. The fix takes seconds to start, not minutes.

The same trick helps you:

  • Review a PR without touching your current work. Check it out in a new folder, run it, then delete the folder.
  • Compare two branches with both dev servers running.
  • Run a slow build in one folder and keep coding in another.

Worktrees vs. Cloning a Few Times

Cloning the repo two, three, or four times works, but each clone is a full copy: the whole history, downloaded and stored again. Four clones means four times the disk. And your branches, commits, and stashes sit in separate copies, so you have to push and pull to move work between them.

Worktrees share one .git. That brings clear wins and a few costs.

The wins:

  • Less disk. One copy of the history, not four.
  • Instant sharing. Commit in one folder and the others see it right away. No fetch or push between them.
  • One source of truth. Remotes, config, and stashes all live in one place.

The costs:

  • They're linked, not independent. Every worktree leans on the same .git. A clone stands on its own.
  • No sharing a branch. The same branch can't be open in two worktrees. Two clones can.
  • One basket. Break the main repo and every worktree feels it.

Rule of thumb: use worktrees for everyday parallel work on one repo. Use a separate clone when you want full isolation, like running risky commands you don't want near your main setup.

List and Clean Up

See all your worktrees:

terminal
1git worktree list

Remove one when you're done:

terminal
1git worktree remove ../app-hotfix

Deleted a folder by hand? Clear the leftover link:

terminal
1git worktree prune

Things to Watch

You can't use the same branch twice. Git won't let one branch live in two folders. You'll see fatal: 'main' is already checked out. Each worktree needs its own branch.

The .git data is shared. Commits, tags, remotes, and stashes all live in one place. Commit in one folder and the others see it right away.

Dependencies are not shared. Each worktree has its own node_modules, so run pnpm install again in a new one. pnpm keeps a shared store, so the second install is fast.

Keep Worktrees Outside the Repo

Put worktrees in sibling folders (../app-hotfix), not inside the project. A worktree inside your repo can confuse file watchers and git status.

Worktrees and AI Agents

Worktrees used to be a niche trick. Now they're key. Once you run more than one coding agent at the same time, each one needs its own space to work.

One worktree per agent solves it. Each gets its own folder and branch, they share one history, and you merge the results at the end.

The Takeaway

Branch switching pushes your whole project through one door, one branch at a time. Worktrees add more doors.

Next time an urgent fix breaks your focus, don't stash and switch. Add a worktree, fix it in a separate folder, and come back to find everything where you left it.

Related Articles

GET IN TOUCH

Let's work together

I build fast, accessible, and delightful digital experiences for the web. Whether you have a project in mind or just want to connect, I'd love to hear from you.

Get in touch

or reach out directly at hello@mohammadshehadeh.com