Worktree は一時的な実行ディレクトリとしてより適しています

以前は、皆さんよくやっていた方法は、まず worktree を準備し、そのディレクトリ内で Codex / Claude Code を開くことでした。初期のモデルはコンテキストや記憶が十分でないため、メインのワークスペース内で直接 worktree を作成させると、コンテキスト圧縮後に現在のディレクトリと作成された worktree ディレクトリを混同しやすく、最終的に混乱を招きます。
しかし、このやり方には副作用もあります。それは、worktree を長期的な作業空間として徐々に使い続けてしまうことです。問題は、worktree はもともとブランチに紐付いているため、時間が経つにつれてブランチの切り替えや同期、クリーンアップといった余計な手間に直面することです。
Worktree と独立したクローンの違いについて、多くの人はあまり明確に理解していません。その利点は「ディレクトリが増えること」ではなく、本質的に同じリポジトリを共有し、git オブジェクトライブラリを共有しているため、コピーコストが低く、ネットワークのクローンを再度行う必要もないことです。これは大規模リポジトリにとって特に便利です。したがって、一時的に並行して実行するディレクトリを作りたいだけなら、worktree は非常に適しています。完全に独立したオブジェクトライブラリが必要な場合、例えば Docker や仮想マシンのサンドボックスにマッピングしたい場合は、ローカルクローンの方が適しています。
少なくとも現在の Codex / Claude Code にとっては、この問題はそれほど深刻ではなくなっています。私は今、メインディレクトリ内で直接作業し、必要に応じて worktree を作成し、変更をマージしてから worktree を削除する方を好んでいます。これにより、worktree の本来の役割—低コストの一時的な実行ディレクトリ—により適合します。長期的に居座る二次作業領域ではありません。
さらに一歩進めて、私が現在試している方法は、グローバルな workspace を維持し、すべてのプロジェクトの Codex をこのディレクトリ内で開き、ルールに従って clone と worktree を管理させることです。こうすれば、グローバルな記憶も連続しやすくなり、複数のプロジェクトを同時に変更する必要がある場合でも、それぞれを順に変更し、最終的にテストを行うことができます。