You're halfway through a feature.
Your working directory is full of changes.
Some files are modified. Some new files haven't been committed yet. You're in the middle of testing something.
Then a message arrives:
There's a high-priority production bug. Can you take a look?
For many developers, the workflow immediately becomes:
git stash
git checkout main
git pull
git checkout -b fix/urgent-bug
Fix the bug.
Commit it.
Switch back.
Then:
git stash pop
And hope everything comes back exactly the way you left it.
Usually, this works.
But it's also an interruption-heavy workflow. Stashes can pile up, conflicts can happen when restoring changes, and you're constantly switching the state of your working directory.
There is another option that works surprisingly well for this situation:
Use git worktree
Git worktrees allow you to have multiple working directories connected to the same repository.
Instead of switching your current directory from one branch to another, you can check out another branch into a completely separate directory.
For example, imagine your repository looks like this:
my-project/
You're currently working on:
feature/new-dashboard
Then an urgent bug appears.
Instead of stashing your work, you can create another worktree:
git worktree add ../my-project-hotfix -b fix/urgent-bug main
Now you have two directories:
my-project/ → feature/new-dashboard
my-project-hotfix/ → fix/urgent-bug
Your feature work remains exactly where it was.
No stash required.
No need to reset your working directory.
No need to restore unfinished changes later.
You simply move into the second directory and work on the bug.
Why Worktrees Can Be Better Than Stashing
The biggest benefit is context preservation.
Your original working directory stays untouched.
That means:
- Uncommitted changes remain in place
- Your current branch stays checked out
- No stash needs to be created
- No stash needs to be restored later
- You can work on multiple branches at the same time
This is especially useful when you regularly switch between:
- Feature development
- Production fixes
- Code reviews
- Release branches
- Experiments
- Multiple tickets
Instead of treating branch switching as a process where you repeatedly pause and restore work, each branch can have its own working directory.
A Basic Worktree Workflow
Create a new worktree
To create a worktree for an existing branch:
git worktree add ../my-project-review review-branch
To create a new branch and worktree:
git worktree add -b fix/urgent-bug ../my-project-hotfix main
See all active worktrees
Git provides a simple command for listing them:
git worktree list
This lets you see which directories and branches are currently connected to the repository.
Remove a worktree
When you're finished:
git worktree remove ../my-project-hotfix
You can then delete branches you no longer need using your normal Git workflow.
A Small Caveat
Worktrees share the same underlying Git repository.
That is usually exactly what you want, but it also means you should understand which branches are checked out in which worktrees.
Git prevents the same branch from being checked out simultaneously in multiple worktrees under normal circumstances.
That's helpful, but it can also confuse developers who are using worktrees for the first time.
A small amount of organization goes a long way.
I usually recommend naming worktree directories based on what you're doing:
project-feature-auth/
project-hotfix-payment/
project-review-pr/
That makes it immediately obvious what each directory is for.
Making Worktree Commands Easier
Git worktrees are powerful, but remembering the exact commands and flags isn't always convenient.
So I built a small visual Git Worktree command builder that helps generate commands for common tasks.
It can help you create commands for:
- Adding worktrees
- Creating branches with worktrees
- Moving worktrees
- Locking and unlocking worktrees
- Removing worktrees
- Cleaning up unused worktrees
You can try it here:
🔗 https://omnikite.vercel.app/tools/developer/git-worktree-add-remove-command-builder
It's free and runs in the browser.
When Should You Use Worktrees?
You probably don't need a separate worktree for every branch.
But they become extremely useful when context switching would otherwise require you to interrupt unfinished work.
For example:
You're halfway through a feature → an urgent bug arrives → open a new worktree → fix the bug → return to your feature exactly where you left it.
No stash.
No restoring.
No trying to remember what state your previous branch was in.
Just separate working directories for separate pieces of work.
Once you get comfortable with git worktree, it can be difficult to go back to constantly stashing and switching branches.
Do you use Git worktrees in your daily development workflow, or are you still relying mostly on git stash when context switching?
Top comments (0)