What Are Git Worktrees, and Why Should You Use Them?

The Git Feature Everyone Is Suddenly Talking About

If you've spent any time in developer communities recently, you've probably noticed git worktrees coming up more and more. Tutorials are being written, YouTube videos are being recorded, and developers are swearing by them as a game-changer for their daily workflow. Here's the slightly ironic part: git worktrees have been available since 2015. They're not new. What's new is that people are finally paying attention — and once you understand what they do, you'll immediately understand why.

In this article, we'll break down exactly what git worktrees are, how they compare to the traditional branch-and-stash workflow, and why you should seriously consider adding them to your development toolkit.

The Problem: Context Switching Is Painful

To understand why worktrees matter, you first need to feel the pain they solve. Picture a familiar scenario: you're deep in the middle of building a new feature — let's say a login system. You've made changes across a dozen files, your editor has a dozen tabs open, and you're finally in the flow state every developer dreams about. Then it happens. A colleague pings you about a critical production bug that needs to be fixed immediately.

Without worktrees, your options aren't great. The most common approach is to stash your current work:

git stash "wip feature login"

Then you switch to the main branch, create a hotfix branch, fix the bug, push it, get it reviewed, merge it, and finally come back to your feature branch and pop your stash. It works, but it's clunky. You lose your mental context, your editor state is disrupted, and if you forget what you stashed or have multiple stashes piling up, things can get messy fast.

There's also a more subtle problem: you can only have one working directory checked out at a time. Your entire repository folder represents a single snapshot of a single branch. Everything else lives in git's object database, invisible and inaccessible until you explicitly switch to it.

What Are Git Worktrees?

Git worktrees solve this by allowing you to check out multiple branches from the same repository simultaneously, each in its own dedicated directory on your filesystem. Think of it like having two or more fully independent working directories, all powered by the same underlying git repository. They share the same git history, the same remotes, and the same object database — but each worktree has its own branch checked out and its own set of uncommitted changes.

You create a new worktree with a simple command:

git worktree add ../my-hotfix-branch hotfix/critical-bug

This creates a new directory called my-hotfix-branch next to your current project folder, with the hotfix/critical-bug branch checked out and ready to go. Your original directory stays exactly as it was — feature in progress, files mid-edit, nothing touched.

When you're done with the hotfix, you can remove the worktree just as cleanly:

git worktree remove ../my-hotfix-branch

No stashing, no context loss, no mental overhead.

Git Worktrees vs. Branches: What's the Difference?

This is a common point of confusion, so it's worth addressing directly. Worktrees are not a replacement for branches — they work alongside them. A branch is a pointer to a commit in your git history. A worktree is a working directory tied to a branch. You can have many branches without multiple worktrees, and you can have multiple worktrees, each checked out to a different branch.

The key distinction is filesystem presence. Without worktrees, only one branch is "materialized" on disk at a time. With worktrees, multiple branches can exist as real, navigable directories simultaneously. You can open both in your code editor, run both in separate terminal sessions, or even run both development servers at the same time — which is enormously useful when you need to test or compare behavior across branches.

Practical Use Cases for Git Worktrees

Once you start thinking in terms of worktrees, you'll find use cases everywhere:

• Urgent hotfixes: As described above, jump to a fix without abandoning your current work or cluttering your stash list.
• Code review: Check out a colleague's pull request branch in a separate worktree so you can review their actual running code while continuing to work in your own branch.
• Long-running experiments: Keep an exploratory branch alive and accessible without committing to it or getting it tangled with your main development work.
• Running multiple environments: Test a new feature against a different version of an API or dependency by running both branches side by side with their own dev servers.
• Documentation updates: Work on a docs-only branch in a separate worktree while your main work continues uninterrupted.

A Few Things to Know Before You Start

Git worktrees are powerful, but there are a couple of rules worth knowing. First, the same branch cannot be checked out in two worktrees at the same time. Git enforces this to prevent conflicts. If you try, you'll get an error. Second, each worktree has its own index and HEAD, so changes you make in one worktree have no effect on another until you commit and merge through the normal git workflow.

You can view all your active worktrees at any time with:

git worktree list

This gives you a clean overview of every directory currently linked to your repository, along with which branch each one has checked out.

Why Are Git Worktrees Having a Moment Right Now?

The honest answer is probably that developer tooling has matured to the point where worktrees fit naturally. Code editors like VS Code and Neovim handle multiple project windows well. Terminal multiplexers like tmux make it easy to manage multiple directory sessions. And as codebases have grown larger and more complex, the cost of a disrupted workflow has become more visible and more painful.

Worktrees were always a good idea. The ecosystem just caught up with them.

Should You Use Git Worktrees?

If you regularly switch contexts mid-feature, review pull requests from teammates, run parallel development environments, or simply find yourself reaching for git stash more than you'd like, then yes — git worktrees are absolutely worth adding to your workflow. They're not complicated to learn, they integrate seamlessly with everything you already do in git, and the productivity gains for the right use cases are immediate and real.

Give them a try the next time an urgent bug interrupts your flow. You might wonder how you ever worked without them.