Git worktrees, a long-underutilized native Git feature, are gaining mainstream adoption as AI-driven parallel development becomes standard, with GitHub designating them the default session mode for its Copilot coding assistant (GitHub’s official guide). The tool lets developers work on multiple branches of the same repository simultaneously without stashing uncommitted changes or disrupting open editor windows. Unlike full repository clones, worktrees share the same Git history and object database as the main repo, cutting redundant disk usage and avoiding synchronization errors between separate copies .
How Git Worktrees Eliminate Traditional Switching Overhead
Traditional Git workflows force developers to complete a multi-step sequence when moving between unrelated tasks, a pain point documented in GitHub’s official developer advocacy blog. For example, a developer working on a feature branch who needs to fix a production bug must first commit or stash in-progress work, checkout the main branch, pull the latest changes, create and checkout a hotfix branch, fix the bug, merge the pull request, then return to their original feature branch and restore stashed work. This process often requires reloading project files, reinstalling dependencies, and reorienting to the context of the original task, creating friction for even small interruptions .
Git worktrees remove this entire sequence by keeping the original branch and editor context fully intact. A single command creates a new, isolated workspace for the unrelated task: git worktree add ../hotfix-workspace -b hotfix-bug main instantly generates a sibling folder named hotfix-workspace, bases it on the latest main branch, and checks out a new hotfix-bug branch . The developer can open this folder in a separate editor window or terminal session to address the bug, while their original editor for the feature branch remains exactly as they left it.
Once the pull request is merged, the temporary workspace can be deleted with git worktree remove ../hotfix-workspace, leaving no leftover stashes or branch clutter . This approach removes the risk of stash conflicts, eliminates editor disruption, and enables true parallel work across unrelated tasks without the overhead of maintaining multiple full repository clones .
Why Worktrees Are Gaining Prominence Now
For years, git worktrees were a niche feature known mostly to advanced Git users. The primary barrier to adoption was that most Git graphical user interfaces either did not support worktrees at all, or treated them as second-class functionality with limited management options . Most development teams followed a linear workflow: create a feature branch, complete work, open a pull request, merge, and repeat, with little operational need for parallel branch access .
That pattern has shifted sharply with the rise of AI-assisted development, which has made parallel work the default for many engineering teams. Developers now routinely run multiple concurrent coding sessions, and code review culture has expanded to cover AI-generated output alongside human-written code . Worktrees align directly with this shift: they allow both human developers and AI agents to work on separate branches in parallel without stepping on each other’s changes, leading GitHub to designate them the default session mode for the GitHub Copilot coding assistant .
This aligns with broader improvements to Copilot’s agentic capabilities, which now support long-running sessions that span planning, editing, debugging, reviewing, and tool orchestration across multiple parallel tasks . By isolating each session in its own worktree, Copilot avoids context bleed between unrelated tasks, improving the efficiency of both AI and human contributors .
Key Tradeoffs to Consider
Git worktrees solve many common workflow pain points, but they come with specific, measurable limitations developers should account for before adopting them broadly.
First, folder management requires active oversight to avoid clutter. Unused worktrees left in the parent directory accumulate over time, creating disorganization for teams with multiple active contributors. While apps like the GitHub Copilot app automatically remove worktrees after sessions end, developers using the command line must manually run git worktree remove to clean up unused directories .
Second, global .gitignore configuration is required if worktrees are stored inside the main repository directory. These folders must be manually added to .gitignore to avoid accidental tracking by Git. Placing worktrees outside the main repo folder — the default for most tools, including the GitHub Copilot app — avoids this issue entirely .
Finally, Git enforces a one-branch-per-worktree restriction: linking a single branch to two separate worktrees simultaneously is explicitly blocked by the system, a built-in guardrail designed to prevent data corruption from conflicting changes to the same branch history .
Getting Started With Worktrees
Developers can use worktrees via the command line, or through native support in tools like Visual Studio Code, which includes full worktree management built directly into its Git interface. This eliminates the need to memorize command line flags for common operations like creating, switching, or removing worktrees .
For users of the GitHub Copilot app, worktrees are enabled by default with no extra configuration required. The app’s home screen includes a dropdown menu to select where to run a new session, with a new worktree set as the default option. Once a session is active, clicking the session name at the top of the app displays the generated worktree name, full file path, associated project, and a full log of changes made during the session .
Bottom line: Git worktrees are a native, low-overhead Git solution for parallelizing branch work without the synchronization overhead of multiple full repository clones, and their default status in GitHub Copilot makes them a high-priority workflow to test for any developer running parallel agentic coding sessions, cross-branch code reviews, or multi-task engineering workflows .
