- AIとの協働作業では、AIと作業ディレクトリを分けたい -> だからGit Worktreeが流行っている
- AIの作業完了=PRが飛んでくる状態
- コミットタイトルにコンテクスト(
@webや@desktop)を追記しておく
はじめに
最近、AIエージェントの登場により、Git Worktree操作のCLIが乱立している印象があります。
自分は、Git Worktree の存在を初めて知った記事で紹介されていた coderabbitai/git-worktree-runner を使っています。
Git Worktreeの流行
もともとGit Worktree自体の登場は、GitHubのブログを見ると2015年頃1ですが、Google Trendsで「Git Worktree」と検索すると、2025年頃から検索数が急増しているのがわかります。
個人開発においても、自分以外に作業できる労働力としてAIエージェントを活用している方も多いと思います。
AIに作業を依頼し、作業完了の通知が飛んでくるのを待つ、というワークフローが一般的になってくると、人間が作業するブランチとAIが作業するブランチを分けたくなります。 そのため、AI作業と人間が作業するブランチを分けるための運用が重要になってきます。
Vibe CodingですべてAI任せのパターンも増えているとは思いますが、複数AIエージェントを何台も動かすとなると結局エージェントの作業がコンフリクトしないように配慮する必要があります。
モノレポの限界
エージェント導入当初、自分の個人開発では、モノレポを活用してWebのUI改善をAIエージェントに任せるときは、自分はロジックのコードのレビューをするなど、コードの関心部分を分けることで、作業を分離していました。 ただ、複数ブランチの同時開発には向かないことやどれだけうまくフォルダ構成を分けけていても修正範囲が広がった際に、AIと自分の作業がコンフリクトすることも増えていました。(自分の手を止めるか、エージェントの作業を待つ)
origantt/├── .git/├── apps/│ ├── web/ # Webアプリケーション (Next.js)│ └── desktop/ # デスクトップアプリ (Tauri)├── packages/│ ├── ui/ # 共通UIコンポーネント│ └── core/ # ガントチャートのコアロジック├── package.json└── turbo.json # Monorepo管理このとき、apps/webとapps/desktopの修正範囲が広がり、package/uiやpackage/coreまで修正範囲が広がることもあり、作業のコンフリクトが増えていました。
Git Worktreeの導入
そんなときGit Worktreeの存在を知って導入を検討しました。
Git Worktreeは、ブランチ毎に複数の作業ディレクトリを同時に持つことができる機能なので、ローカルPC内で自分とそれ以外のAIエージェントがそれぞれ別のスペースで作業を進めることができます。
Git Worktree の利点や操作は他の記事を参考にしてもらえればと思います。
しかし、Git Worktreeを使えば、1つのリポジトリに対して複数のワークスペース（working trees）を同時に持つことができます。
ディレクトリとブランチの関係
これにより、ブランチ切り替えのオーバーヘッドをゼロにし、コンテキストスイッチの負荷を劇的に軽減できます。
本記事では、Git Worktreeを用いた開発の利点から、それに合わせたブランチ戦略、コミット規約、そして具体的なワークフローまでを網羅的に解説します。
通常のGitを利用したチーム開発
Git Worktree を利用した開発
このように構造はほぼ同じです。
なので、既存のブランチ戦略とGit Worktreeを組み合わせれば、AIエージェントとの開発を効率化できると考えました。
Git Worktree 使用の基本的な流れ
基本的な流れは以下の通りです。
- Git Worktreeは一つのブランチに紐づいている
- Agentはタスクごとに切り出されたWorktree=ブランチで作業する
- Worktree毎にコミットを進める
npm install やビルドに時間がかかるプロジェクトでは、ブランチ切り替えのたびに依存関係の再インストールやリビルドが発生し、開発リズムが崩れがちです。
Worktreeごとに異なる依存関係やビルド状態を維持できるため、作業の切り替えコストがほぼゼロになります。
推奨ブランチ戦略とWorktreeの最適化
Git Worktreeを導入する場合、どのブランチ戦略が適しているでしょうか。
主要なブランチ戦略の比較
| 戦略 | 特徴 | Worktreeとの相性 |
|---|---|---|
| Gitflow2 | develop, master, release/*, feature/* など多層構造。 | △ ブランチ管理が複雑になりがち。 |
| GitHub Flow3 | main から分岐し、PRでマージ。シンプル。 | ◯ 非常に良い。常に最新の main を参照するWorktreeと、作業用Worktreeを用意。 |
| Trunk-Based4 | main に直接（または短命なブランチで）頻繁にマージ。 | ◯ 高速な開発サイクルとWorktreeの「切り替えコストゼロ」がマッチする。 |
GitHub Flow または Trunk-Based Development を推奨します。
私は個人開発で、GitHub Flowを採用しています。 基本的に、最新の状態をmainブランチに保ち続けるのが基本的な方針になります。
自分の場合は、
- メインの開発ブランチはmainブランチ
- リリースは、releaseブランチにmainをマージしてリリース
- Git Worktreeの変更は、mainブランチにマージ(このとき
--ff-onlyでマージ) - マージしたブランチで開発を継続する場合は、mainブランチにリベース
--ff-onlyは好みの問題だと思いますが、
このようにして、他人(=AIエージェント)の作業をmainブランチに取り込みつつ、作業を進めます
Worktree利用時の推奨構成
ディレクトリ構成としては、以下のように「ベアリポジトリ」を中心とした構成が扱いやすいです。
project-root/├── .git/ (bare repository)├── main/ (主幹ブランチ用Worktree)├── feature/desktop (デスクトップ機能開発用Worktree)├── feature/parser (パーサ開発用Worktree)└── fix/bug (バグ修正用Worktree)このように配置することで、プロジェクト全体の見通しが良くなり、ディレクトリ移動だけでブランチ（作業環境）を切り替えられます。
これをGitGraphで表すと、以下のようにそれぞれのWorktreeが独立したブランチとして機能しているイメージになります。
GitGraphでの表示例(Before)
GitGraphでの表示例(After)
ここで、feature/desktopの更新が完了した場合は、mainブランチにリベースして、以下のようになります。
(必要があれば)他ブランチでもmainにリベースして,更新を取り込む (下図は、すべてのブランチをリベースした後)。
コミット規約：Conventional Commits
Worktreeで効率よく開発を進める中で、コミットメッセージの品質も重要です。
Conventional Commits の導入したうえで、コミットタイトルに @{Context} を付けると、非常に便利でした。
Contextには、どのWorktreeで開発を行ったかを示すことができます。
コミットメッセージ例
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 @parser私は、モノレポ内のフォルダ毎にWorktreeを作成して開発を行っていたので、@web @desktop @parser のようにContextを付けました。
これにより、Git Logを見たときにどのWorktreeで開発を行ったかが一目でわかりやすく変更を追うのが楽になりました。
注意点と回避策
このように、便利なGit Worktreeですが、いくつか注意点があります。
おわりに
Git Worktreeは、一度慣れてしまうと「なぜ今まで使っていなかったのか」と思うほど強力な機能でした。
個人開発でもAIエージェントとの開発が増えていると思いますので、ぜひ、活用してみてください。
