Git Worktree Strategy for AI-Assisted Development Git Worktree Strategy for AI-Assisted Development

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 Management

In 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

💻 Other PC1

💻 Other PC2

💻 My PC

Index omitted

Index omitted

Index omitted

Push / Pull

Push / Pull

Push / Pull

💻 Server (GitHub/GitLab)

.git/ (Remote Repo)

.git/ (Local Repo)

📂 Working Directory
Branch: main

.git/ (Local Repo)

📂 Working Directory
Branch: fix/bug

.git/ (Local Repo)

📂 Working Directory
Branch: feature/desktop

Development with Git Worktree

📁 Repository

Linked Worktrees

📂 .worktrees/feature-desktop/
(Branch: feature/desktop)

.git/
(Shared Object Database)

📂 . (Main Worktree)
(Branch: main, release, etc...)

📂 .worktrees/fix-bug/
(Branch: fix/bug)

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

StrategyFeaturesCompatibility with Worktree
Gitflow2Multilayered structure (develop, master, release/*, feature/*, etc.).△ Branch management can get complicated.
GitHub Flow3Simple: branch from main, merge via PR.◯ Excellent. Keep a Worktree for the latest main and others for tasks.
Trunk-Based4Frequent 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:

  1. Use the main branch as the primary development branch.
  2. For releases, merge main into the release branch.
  3. Merge Git Worktree changes into the main branch (using --ff-only).
  4. To continue development on a merged branch, rebase it onto the main branch.

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.

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)

mainreleasefeature-desktopfeature-parserfix-buginit1-beb5bb4...3-ec43593release: 1.0.0feat: desktop1feat: desktop27-6adbb6d8-6a46a8a

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).

mainreleasefeature-desktopfeature-parserfix-buginit1-fa76876...3-43497b8release: 1.0.0feat: desktop1feat: desktop2release: 2.0.09-aa1852f10-b0f3c29

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 @desktop
update: remove redundant parse milestone @parser
feat: strike through deleted task name @web
fix: align highlight color dropdown width @web
update: `docs/release_plant.puml`
fix: config page scroll behavior @web
add: `AGENTS.md`
feat: parse with source map @parser

Since 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

  1. https://github.blog/open-source/git/git-2-5-including-multiple-worktrees-and-triangular-workflows/

  2. https://nvie.com/posts/a-successful-git-branching-model/

  3. https://docs.github.com/en/get-started/using-github/github-flow

  4. https://trunkbaseddevelopment.com/


← Back to blog