Git worktrees are making a quiet comeback. The feature, which lets developers check out multiple branches at once without switching directories, has been around for years. But a shift in how code is written — driven by AI tools like GitHub Copilot — is pushing worktrees from a niche utility to a near-essential part of modern development workflows.
What worktrees do
A standard Git workflow usually involves one working directory. To work on a different branch, you stash changes, switch branches, then resume. Worktrees bypass that dance. They create separate directories for each branch, each with its own working tree. That means a developer can have the main branch open in one editor window, a feature branch in another, and a hotfix branch in a third — all at the same time, all with their own files and dependencies.
It’s a feature that Git has supported since version 2.5, released in 2015. For years it was a tool favored by a subset of power users and teams with complex branching models. Now, according to developers who track tooling trends, worktrees are gaining a wider audience.
The AI connection
The catalyst appears to be the rise of AI-assisted coding. GitHub Copilot and similar tools can generate code quickly, so developers often find themselves juggling multiple lines of thought — testing a suggestion on one branch while reviewing an existing pull request on another. Worktrees let them do that without constant context switching.
“When you’re iterating fast with Copilot, the last thing you want is to lose your place because you had to stash changes,” one developer wrote in a forum post that circulated widely among engineering teams. The post, which the developer later removed, captured a sentiment that many in the community share: worktrees make parallel experimentation practical.
Several large engineering organizations have recently updated their internal Git documentation to recommend worktrees as a best practice. They cite reduced merge conflicts and faster review cycles as direct benefits when teams use multiple branches in parallel.
Why now?
It’s not just AI tools. The broader trend toward trunk-based development and continuous deployment has also made worktrees more relevant. In a trunk-based model, developers create short-lived feature branches that are merged back to the main line frequently. Worktrees let them prepare those branches simultaneously, then merge them in quick succession without waiting for one to finish.
Git itself hasn’t changed the worktree feature in years. The command set remains stable: git worktree add, git worktree list, git worktree remove. What’s changed is how developers use it. Tooling around worktrees is also improving. Several editor extensions now detect worktrees automatically and offer to open branches in new windows, removing the manual setup that once discouraged adoption.
Still a learning curve
Adopting worktrees isn't frictionless. Developers who start using them often hit confusion around cleanup — when a branch is deleted, the corresponding worktree directory lingers unless manually removed. And some CI/CD tools don’t handle multiple worktrees gracefully, requiring teams to tweak their build scripts.
But the tradeoff is becoming harder to ignore. As AI coding assistants push development speeds higher, the bottlenecks are shifting from writing code to managing branches. Worktrees offer one way to unblock that bottleneck.
The question now is whether Git will evolve worktrees further — perhaps adding built-in lifecycle management — or whether third-party tools will fill the gap. For developers already using Copilot or similar tools, the answer may come down to how many directories they’re willing to keep open at once.
