Git Worktree Strategy for AI-Assisted Development
Why Use Git Worktree with AI Agents?
Recently, with the rise of AI agents, there seems to be a proliferation of CLI tools for Git Worktree operations.
I personally use coderabbitai/git-worktree-runner, which was introduced in the article where I first learned about Git Worktree.
The Rise of Git Worktree
Git Worktree itself was introduced around 2015, according to the GitHub blog1, but Google Trends shows a sharp increase in searches for “Git Worktree” starting around 2025.
In solo development, many people are now using AI agents as an additional workforce.
When a workflow becomes common where you delegate tasks to an AI and wait for a notification of completion, you naturally want to separate the branches (and working directories) where humans work from those where AI agents work. Therefore, establishing a strategy for managing AI and human branches becomes crucial.
While “Vibe Coding” (leaving everything to AI) is on the rise, if you run multiple AI agents simultaneously, you still need to ensure their work doesn’t conflict.
Limitations of Monorepos
When I first introduced agents into my solo projects, I used a monorepo to separate concerns. For example, when letting an AI agent improve the Web UI, I would focus on reviewing the logic code. However, monorepos are not inherently designed for concurrent work on multiple branches within the same directory. No matter how well the folder structure is organized, conflicts often occurred when the scope of changes expanded, forcing me to either stop my work or wait for the agent to finish.
origantt/├── .git/├── apps/│ ├── web/ # Web Application (Next.js)│ └── desktop/ # Desktop Application (Tauri)├── packages/│ ├── ui/ # Shared UI Components│ └── core/ # Core Logic for Gantt Charts├── package.json└── turbo.json # Monorepo ManagementIn such cases, if changes in apps/web and apps/desktop expanded to packages/ui or packages/core, work conflicts became more frequent.
Understanding Git Worktree Basics
That’s when I discovered and considered Git Worktree.
Git Worktree allows you to have multiple working directories associated with a single repository simultaneously. This means you and your AI agents can work in separate spaces on the same local machine.
You can refer to other articles for the basic benefits and operations of Git Worktree.
With Git Worktree, you can have multiple working trees for one repository at the same time.
Relationship Between Directories and Branches
This eliminates the overhead of switching branches and drastically reduces the cognitive load of context switching. In this article, I will cover everything from the advantages of Git Worktree to the branching strategy, commit conventions, and specific workflows that complement it.
Traditional Team Development with Git
Development with Git Worktree
The structures are almost identical. Therefore, I realized that combining existing branching strategies with Git Worktree could streamline development with AI agents.
Basic Workflow with Git Worktree
The basic flow is as follows:
- Each Git Worktree is tied to one branch.
- Agents work on a specific Worktree/branch for each task.
- Commits are made within each Worktree.
In projects where npm install or builds take a long time, switching branches often triggers dependency re-installation or re-builds, disrupting the development flow. Since each Worktree maintains its own dependencies and build state, the cost of switching tasks is virtually zero.
Best Branching Strategies for Worktrees
Which branching strategy is best when using Git Worktree?
Comparison of Major Branching Strategies
| Strategy | Features | Compatibility with Worktree |
|---|---|---|
| Gitflow2 | Multilayered structure (develop, master, release/*, feature/*, etc.). | △ Branch management can get complicated. |
| GitHub Flow3 | Simple: branch from main, merge via PR. | ◯ Excellent. Keep a Worktree for the latest main and others for tasks. |
| Trunk-Based4 | Frequent merges directly to main (or short-lived branches). | ◯ Matches the high-speed development cycle and zero-cost switching of Worktree. |
I recommend GitHub Flow or Trunk-Based Development.
In my solo development, I use GitHub Flow. The fundamental policy is to keep the main branch in its latest state.
My personal workflow:
- Use the
mainbranch as the primary development branch. - For releases, merge
maininto thereleasebranch. - Merge
Git Worktreechanges into themainbranch (using--ff-only). - To continue development on a merged branch, rebase it onto the
mainbranch.
Whether you use --ff-only is a matter of preference, but this allows me to incorporate the work of “others” (AI agents) into the main branch while continuing my own work.
Recommended Configuration for Worktree
A “Bare Repository” based setup is easy to manage:
project-root/├── .git/ (bare repository)├── main/ (Worktree for the main branch)├── feature/desktop (Worktree for desktop feature development)├── feature/parser (Worktree for parser development)└── fix/bug (Worktree for bug fixes)This layout provides a clear overview of the project, allowing you to switch branches (working environments) simply by changing directories.
Visualizing this with GitGraph:
GitGraph Example (Before)
GitGraph Example (After)
If the updates for feature/desktop are completed, it’s rebased onto the main branch as shown below.
(If necessary, other branches are also rebased onto main to incorporate updates. The diagram below shows the state after all branches have been rebased).
Commit Convention: Conventional Commits
Quality commit messages are vital when working efficiently with Worktree. I found it extremely useful to adopt Conventional Commits and add @{Context} to the commit title. The Context indicates which Worktree the development was performed in.
Commit Message Examples
fix: second milestone preview error @desktopupdate: remove redundant parse milestone @parserfeat: strike through deleted task name @webfix: align highlight color dropdown width @webupdate: `docs/release_plant.puml`fix: config page scroll behavior @webadd: `AGENTS.md`feat: parse with source map @parserSince I create Worktrees for each folder in my monorepo, I use contexts like @web, @desktop, and @parser. This makes it much easier to track changes when looking at the Git log, as I can instantly see where the development took place.
Precautions and Workarounds
While Git Worktree is powerful, there are a few things to keep in mind.
Conclusion
Once you get used to Git Worktree, you’ll wonder how you ever worked without it. As AI-assisted solo development becomes more common, I highly recommend giving it a try.
Footnotes
← Back to blog