Git Worktree Guide: Manage Multiple Branches Without Stashing
Master git worktree to handle multiple branches simultaneously. Stop stashing, avoid context switching, and improve your git workflow optimization today.
We’ve all been there: you’re deep into a complex feature branch, the build is half-broken, and suddenly a high-priority bug report lands. The old-school approach is to git stash, switch branches, fix the bug, switch back, and pray you don't lose track of your local changes. It’s a context-switching nightmare that wastes time and introduces unnecessary risk.
Using git worktree changed how I manage my local environment. Instead of forcing a single directory to hold one branch at a time, worktrees allow you to check out multiple branches into separate, linked directories.
Why use git worktree for your workflow?
The core problem with standard Git usage is that the index and working directory are tied to a single HEAD. git worktree decouples these, letting you link multiple directories to the same .git repository.
When I started using this for my Laravel bug fixes, maintenance & optimization client projects, I saw an immediate shift in my focus. I could keep a "production-ready" branch in one folder and a "feature-in-progress" branch in another. No more git stash dance. If you've ever felt like your current Git undo changes process is too slow because you're constantly cleaning up your state, this is the solution.
Getting started with git worktree
The syntax is straightforward. Assuming you're in the root of your project, you can create a new worktree with:
Bash# Create a new directory 'hotfix-urgent' linked to the 'hotfix' branch git worktree add ../hotfix-urgent hotfix
Git will create a new directory at the same level as your current project and check out the hotfix branch there. You now have two independent working directories sharing the same Git history.
Here is a quick comparison of the standard workflow versus using worktrees:
| Feature | Standard Workflow | Git Worktree |
|---|---|---|
| Context Switching | Requires git stash or commit | None |
| Build Artifacts | Often clobbered | Isolated per folder |
| Disk Usage | Lower | Slightly higher |
| Complexity | Low | Moderate |
Managing your worktrees
Once you've created a few, you'll want to keep track of them. You can list all active worktrees by running:
Bashgit worktree list
This command shows you exactly which branch is checked out in which directory. When you're done with a task, don't just delete the folder. Use Git to clean it up properly:
Bash# Remove the worktree and the associated directory git worktree remove ../hotfix-urgent
Common pitfalls
I initially tried to use worktrees for everything, but there's a caveat: you cannot check out the same branch in two different worktrees at once. Git will throw an error if you try to add a branch that is already active in another worktree.
Also, if you're working on something that requires a Git cherry-pick to move work between these branches, remember that your Git configuration (like your hooks or config) is shared. If you have local-only hooks, they'll fire in every worktree.
Is this git workflow optimization for you?
If you are a solo developer working on one thing at a time, this might be overkill. But if you find yourself frequently juggling hotfixes, review branches, and long-running features, the overhead of managing a few extra folders is worth it. It’s a form of developer workflow improvement that allows you to keep your mental state intact while jumping between tasks.
I still occasionally get lazy and just git stash a small change, but for any task expected to take longer than about 20 minutes, I reach for git worktree every time. It’s one of those "hidden" Git features that, once learned, makes the standard git checkout feel like using a typewriter in the digital age.
Frequently Asked Questions
Does git worktree copy the whole repo?
No. It creates a new working directory and a small metadata file, but it references the existing .git directory. It’s very lightweight.
Can I use git worktree with submodules?
Yes, but it gets tricky. Submodules are tied to the directory structure. If you use submodules, you'll need to run git submodule update --init inside the new worktree directory after creating it.
What happens if I delete a worktree folder manually?
Don't do it. Git will lose track of the worktree, and you'll have to manually clean up the .git/worktrees directory. Always use git worktree remove to keep your repository state healthy.
Next time you feel the urge to stash, try spinning up a new worktree instead. It might feel weird for a day, but the reduction in context-switching friction is massive. I'm still experimenting with how to integrate this into my CI/CD pipelines, specifically when running GitHub Actions locally, so I'll report back if I find a cleaner way to handle shared dependencies.