Git ワークツリー（git worktree）を使うと、開発者は単一のリポジトリから、同じリポジトリの複数のブランチをそれぞれ別のディレクトリに同時にチェックアウトできる。エージェント型コーディングでは、これにより並列に動く複数のエージェントのそれぞれに隔離された作業コピーが与えられ、実行中に互いの変更が干渉しなくなる。
用法
Osmani は、Claude Code 自身のドキュメントが、インスタンス同士が干渉しないよう並列セッションには git worktree を使うことを明示的に推奨していると述べ、また Anthropic のベストプラクティスのガイダンスが、worktree の使い方を段階的に示すとともに、「worktree ごとにターミナルタブを 1 つ」という運用パターンを示していると引用している。彼はこの手法を、チームの協調から借りた明示的な境界ルールと組み合わせている。1 つのエージェントが 1 つのプルリクエストを担当し、複数のエージェントの成果を寄せ集めた巨大な PR は作らないこと。2 つのエージェントが同じファイルに触れる可能性がある場合は、代わりにタスクの分割を設計し直すこと。そして共有インターフェースは、人間が主導する最初のプルリクエストで扱い、エージェントはその上に構築すること、である。
適用される場面
Git ワークツリーは、同じリポジトリに対して複数のコーディングエージェントを並列に実行する際に、それらが同じ作業コピーを同時に編集するのを防ぐために用いられる。ソースは、隔離されたディレクトリだけでは不十分だと位置づけている。マージコンフリクトはツールの失敗ではなく境界設定の失敗だと説明されており、そのため worktree は上記のタスク境界ルールの代わりとしてではなく、それと組み合わせて使われる。Osmani の説明によれば、このプラクティスはこの投稿自身の発案ではなく、Claude Code 自身のドキュメントと Anthropic のベストプラクティスのガイダンスの両方で推奨されているパターンとして提示されている。
後の投稿では、Cursor のバックグラウンドのクラウドエージェントが、同じ手法をホスト型製品のレベルで用いていることが説明されている。長時間動作する各バックグラウンドエージェントはそれぞれ隔離された git worktree の中で動作し、その結果をプルリクエストを通じてコードベースにマージし戻す。そのため、ローカルで開始したタスクをクラウドに引き渡し、他の作業と衝突することなく後で再びアタッチすることができる。