Git Worktrees Are Having a Moment — Here's Why
If you've spent any time in developer communities recently, you've probably noticed a surge of interest in git worktrees. Blog posts, YouTube tutorials, and social threads are all raving about them. What's funny, though, is that git worktrees have been around since 2015. They're not new — they're just newly discovered by a generation of developers who are tired of fighting with git stash.
So what exactly are git worktrees, why are they suddenly so popular, and — most importantly — should you start using them in your own workflow? Let's break it all down in plain language.
The Problem: Context Switching Is Painful Without Worktrees
To understand why git worktrees matter, you first need to appreciate the problem they solve. Imagine you're deep into building a new feature on your current branch. You've made edits across a dozen files, some of which aren't ready to commit. Then a message pops up: there's an urgent production bug, and you need to drop everything and fix it right now.
In a traditional git workflow, your options are limited and none of them feel great. You could commit your unfinished work with a throwaway commit message, which pollutes your history. Or you could use git stash to temporarily shelve your changes before switching branches. That looks something like this:
git stash "wip feature login"Then you switch to the hotfix branch, fix the bug, commit, push, open a pull request — and then you need to remember to pop your stash, hope nothing conflicts, and get back into the headspace you were in before the interruption. It works, but it's clunky, error-prone, and mentally taxing. Stashes can pile up, get forgotten, or cause gnarly merge conflicts when you finally restore them.
There's also another limitation that stashing doesn't solve at all: what if you need to have two branches open at the same time, running simultaneously? For example, what if you want to keep a dev server running on your feature branch while you also browse and test code on the main branch? With the traditional model, that's simply not possible in a single working directory.
What Is a Git Worktree?
A git worktree is a feature that allows you to check out multiple branches of the same repository into separate directories on your filesystem — all at the same time. Each worktree has its own working directory and its own checked-out branch, but they all share the same underlying git repository and its history.
Think of it like this: instead of one apartment that you have to completely redecorate every time you want a different look, you now have several apartments in the same building, each styled differently, and you can walk between them freely at any moment.
Creating a new worktree is straightforward. If you want to work on a hotfix while keeping your feature branch intact, you can run:
git worktree add ../hotfix-branch origin/hotfix-branchThis creates a new directory called hotfix-branch alongside your main project folder, with that branch already checked out and ready to go. You switch to it simply by navigating to that folder in your terminal or opening it in your editor. No stashing. No conflict risk. No mental overhead.
Git Worktrees vs. Branches: What's the Difference?
This is a common source of confusion, so it's worth being precise. Branches and worktrees are not the same thing, and worktrees don't replace branches — they complement them.
- A branch is a pointer to a specific commit in your git history. It represents a line of development.
- A worktree is a physical directory on your disk where a branch is checked out and actively being worked on.
Normally, you have one worktree — your project's main folder — and you switch branches inside it. With git worktrees, you can have multiple directories, each with a different branch checked out simultaneously. You still use branches for all the same reasons you always did; worktrees just change how you interact with them physically on your machine.
One important rule: you cannot check out the same branch in two worktrees at the same time. Git prevents this to avoid conflicts. Each branch can only live in one worktree at a time, which keeps everything clean and consistent.
Why Are Developers Loving Git Worktrees Right Now?
The renewed interest in git worktrees lines up with a few trends in modern development. Codebases are getting larger, meaning switching branches often triggers long rebuild or reinstallation times (think npm install or recompiling dependencies). With worktrees, each directory maintains its own node_modules or build artifacts, so you don't have to reinstall everything every time you switch contexts.
There's also growing adoption of tools like Claude Code and other AI-assisted development environments where running parallel agents on different branches simultaneously is increasingly common. Git worktrees make that kind of parallel workflow much more manageable.
Additionally, worktrees pair beautifully with modern terminal multiplexers and multi-pane editors, letting developers literally see two branches side by side and run two servers at once without any juggling.
When Should You Use Git Worktrees?
Git worktrees are especially useful in these scenarios:
- You need to respond to an urgent bug fix without losing your in-progress feature work.
- You want to run two versions of your application side by side for comparison or testing.
- You're doing a code review and want the reviewed branch in a separate directory so your editor's state isn't disrupted.
- You're working with long-running processes (dev servers, build watchers) that you don't want to kill when switching tasks.
- You're using AI coding agents that benefit from isolated, concurrent working environments.
Getting Started with Git Worktrees Today
If you've never used git worktrees before, the learning curve is minimal. The core commands you need are git worktree add to create a new worktree, git worktree list to see all active worktrees, and git worktree remove to clean up when you're done. That's genuinely most of what you need to know to get started.
Git worktrees have been quietly sitting in your git installation for nearly a decade, waiting for you to discover them. Now that you have, there's a good chance you'll wonder how you ever managed without them. Give them a try on your next context switch — your stash list will thank you.