Blog
Long-form behind the videos.No filler, real projects.
Build notes, coding lessons, and honest reviews from the projects behind each video.
Blog
Build notes, coding lessons, and honest reviews from the projects behind each video.
Git worktree shipped in 2015 as a feature for developers who needed multiple working directories from a single repository. A decade later, AI coding agents have given it a perfect new use case: running multiple agents in parallel without them overwriting each other's files.
Git worktree shipped in 2015 as a feature for developers who needed multiple working directories from a single repository. A decade later, AI coding agents have given it a perfect new use case: running multiple agents in parallel without them overwriting each other's files.
Git worktree allows a single Git repository to have multiple working directories, each checked out on its own branch, while sharing the same underlying Git history and object store. Instead of cloning a repository multiple times or stashing and switching branches repeatedly, you create additional working directories that are lightweight and connected to the same repository.
This was originally designed for developers who needed to work on multiple branches simultaneously: fixing a bug on one branch while reviewing a pull request on another, for example, without disrupting the main working directory. The feature has been part of Git since version 2.5.
The core command is git worktree add, which creates a new working directory linked to your repository on a specified branch. Each worktree operates independently: you can have one worktree on a feature branch, another on a bugfix branch, and a third on a refactor branch, all from the same repository. Because they share the Git object store, the disk and time overhead is minimal compared to full clones.
In a multi-agent workflow, you assign each agent a worktree and a task. One agent builds a feature, another fixes a bug, and a third runs a refactor, each in its own isolated working directory. When the agents finish, you review the changes on each branch and merge them. The agents never touch each other's files during execution, which eliminates the most common source of parallel-work conflicts.
Git worktree is not a replacement for proper branch management and code review. Even with isolated working directories, merging multiple branches can produce conflicts that require manual resolution. The feature also adds filesystem complexity: you need to track which worktree is on which branch and clean up worktrees when they are no longer needed. Some tools and IDEs may not fully understand worktree setups, which can cause confusion in environments that expect a single working directory per repository. Finally, worktrees share the same Git object store, so corruption or lock issues in the shared store can affect all worktrees.
Git worktree is for developers running multiple AI coding agents in parallel on the same repository, and for human developers who need to work on multiple branches simultaneously without constant stashing and switching. If your workflow involves one agent at a time, the overhead of worktrees is unnecessary. If you are orchestrating multiple agents or frequently context-switching between branches, worktrees solve a real problem.
An old Git feature found its ideal use case a decade later. The multi-agent era did not need a new tool: it needed a better workflow for an existing one.