The Moment for Git Worktrees
Photo by Jahoo Clouseau from Pexels
What are Git Worktrees?
Git worktrees are a feature that allows you to have multiple working directories from the same repository, each potentially on different branches. Think of it as having multiple "copies" of your project that all share the same Git history but can work on different branches simultaneously.
When you initialize a Git repository, you get your main worktree (the directory where you ran git init or git clone). From there, you can create additional worktrees that are linked to the same repository but exist in separate directories.
Here are the essential commands you'll need:
# Create a new worktree for a specific branch
git worktree add ../my-feature
# List all worktrees
git worktree list
# Remove a worktree when you're done with it
git worktree remove ../my-feature
The relationship is simple: your original repository remains the "main" worktree, and any additional worktrees are linked to it. They all share the same .git directory, which means commits, branches, and history are synchronized across all worktrees.
How is it different from regular branches?
With regular Git branches, you're confined to working in a single directory. When you want to switch between branches, you need to git checkout or git switch, which means saving or stashing your current work, switching the entire working directory to the new branch, and then resuming work. This context switching can be disruptive, especially when you're juggling multiple tasks or need to quickly reference code from another branch.
Git worktrees eliminate this friction by giving each branch its own physical directory. You can have your main branch running in one terminal tab, a feature branch in another, and a hotfix branch in a third - all simultaneously.
Each directory maintains its own state: uncommitted changes, running processes, and even different dependency installations if needed. This separation makes multitasking not just possible, but actually pleasant.
Why now (a decade after release)?
Until a few weeks ago, I wasn't aware this command even existed in Git. I had stumbled upon my own "hack" - cloning the same repository multiple times with different branches to work on several tasks simultaneously. When I shared this approach with a colleague, he said, "Oh, you should check out worktrees. It might be a better fit for this use case."
That's when I discovered that Git has had this feature since 2015, but it somehow flew under my (and most developers) radar. Intrigued, I decided to spend a week experimenting with worktrees to see if they could replace my cloning approach.
During this trial period, I set up three different worktrees for my current project: one for a major feature I was developing, another for urgent bug fixes that kept coming up, and a third for some technical debt cleanup that I'd been putting off. The setup was surprisingly smooth, and I found myself naturally gravitating toward using different terminal windows for different worktrees.
What struck me most during this experiment was how the mental model changed. Instead of thinking "I need to switch branches," I started thinking "I need to switch contexts" - and each context had its own physical space. This subtle shift made multitasking feel less chaotic and more intentional.
The timing of my discovery wasn't coincidental though. The rise of AI coding assistants like Claude Code (Anthropic's AI-powered development environment) and Cursor (an AI-first code editor) has fundamentally changed how we approach development work. These tools have made worktrees not just convenient, but genuinely effective.
Here's where it gets interesting: AI agents (autonomous AI systems that can write, modify, and test code independently) excel at handling isolated, well-defined tasks. When you point Claude Code at a specific worktree with a clear objective, it can work autonomously without the mental overhead of context switching that plagues human developers. This combination of physical isolation (separate directories) and logical isolation (focused tasks) creates an ideal environment for AI-assisted development.
Through experimentation, I've identified three main use cases where worktrees truly shine:
Long-running Side Tasks
Perfect for dependency updates, documentation improvements, or refactoring tasks that you want to chip away at over time without disrupting your main development flow. I keep a dedicated worktree for these maintenance tasks, allowing me to make progress on them during natural breaks in feature development.
Environment Experimentation
Need to test with a different Node version? Want to try a new dependency without breaking your current setup and having to reinstall node_modules? Worktrees let you maintain completely isolated environments while keeping everything in the same repository. This is particularly valuable when you need to compare performance or behavior across different configurations.
AI Agent Parallel Work
This is where worktrees truly excel in 2025. Each AI agent gets its own sandbox to work in, reducing the cognitive overhead of task switching and making it easier to review and integrate changes systematically. I found myself setting up different worktrees for different types of tasks:
- One worktree for the main feature branch where I need more focus and precision
- Another for some bugfix that needed to be done quickly
- A third for refactoring legacy code
Current Limitations and Future Potential
While experimenting with this approach, I initially thought I'd discovered an unbeatable hack - multiple unrelated tasks running simultaneously, with me just orchestrating from above. My backlog would be cleaned out in a day!
However, after about a week of testing, I discovered some realistic limitations. For production code, the real bottleneck often becomes code review capacity. Every line entering your codebase still needs to be understood and validated, and AI-generated code sometimes requires even more careful review than human-written code.
You can spin up as many worktrees as you want and assign AI agents to each one, but eventually all their work flows through your review process. This mirrors the same scaling challenge we've always had with teams: adding more developers doesn't automatically increase output if review capacity doesn't scale with it.
Context switching between worktrees also remains a challenge. While the technical barriers are removed, the mental overhead of juggling multiple tasks simultaneously is still very real.
That said, even with these limitations, I've found worktrees provide a meaningful productivity boost for certain types of work. The key is understanding when and how to use them effectively, rather than expecting them to be a silver bullet.
Despite these realistic constraints, my experience over the past few weeks has convinced me that worktrees represent something significant for modern development workflows.
Conclusion
Git worktrees have become an essential part of my development workflow, not because they're revolutionary, but because they solve a very specific modern problem: how to manage multiple concurrent development streams in the age of AI assistance.
The beauty of git worktrees isn't in their technical complexity - they're actually quite simple. It's in their timing. They've been quietly waiting for a decade for the right use case to make them indispensable. With AI coding assistants becoming our collaborative partners rather than just tools, worktrees have found their moment.
Sometimes the best features are the ones that have been there all along, just waiting for the right context to make them essential. While git worktrees won't make you deliver 10 times faster, they might make you 2-3 times more efficient, and that's a meaningful boost that would have been hard to imagine just a few years back.