なぜ新しいworktreeは毎回「新規インストール」のように感じるのか
Gitのworktreesは、複数のブランチを同時に管理するための強力な手段です。単一のリポジトリ履歴を共有しつつ、各worktreeが個別の作業ディレクトリを保持します。この分離は、複数の機能を並行して開発したり、複数のAIコーディングエージェントを動かしたりする際に非常に便利です。
しかし、落とし穴があります。新しいworktreeはほぼ空の状態で始まります。Gitはコードをコピーしますが、追跡対象外（untracked）のファイルやディレクトリは意図的に無視されます。つまり、JavaScriptプロジェクトのnode_modules、..env設定ファイル、Rustのtarget/ビルドディレクトリといった重要なコンポーネントが完全に欠落してしまうのです。
その結果、新しいworktreeを作成するたびに、フルコールドインストールとビルドプロセスが必要になります。依存関係の再インストール、コードの再コンパイル、キャッシュの再生成を行わなければなりません。5つや10ものコーディングエージェントを動かし、それぞれが独自の環境を必要とする場面を想像してみてください。
各エージェントはそれぞれnpm installやcargo buildなどのセットアップを実行します。これにより負荷が倍増します。5つのエージェントがあれば、5回分のインストール、5回分のコールドビルド、そして5倍のディスク容量が必要になります。有用な作業を開始する前に、準備だけで多大な時間、CPUリソース、そして数ギガバイトのストレージを消費してしまうのです。
高速化の裏にあるCopy-on-Writeという近道
Rust製のオープンソースCLIツールであるWorktrunkは、wt step copy-ignoredコマンドでこの問題に対する賢い解決策を提供します。このユーティリティは、ファイルシステム機能であるCopy-on-Write (CoW)を活用し、選択した無視ファイルを従来のフルコピーなしで、ほぼ瞬時に新しいworktreeへ持ち込みます。
Copy-on-Writeは巧妙なトリックです。ファイルは初期状態でディスク上の同じブロックを共有します。一方のworktreeでファイルを変更すると、ファイルシステムは「変更された」ブロックのみを新しい場所にコピーします。これにより、worktree間の分離を維持しながら、巨大なファイルの重複による初期コストを回避できます。魔法のように、実際にデータが分岐したときだけ容量を消費する複数のコピーを持っているような状態です。
このアプローチにより、セットアップが劇的に高速化します。動画では目覚ましい成果が示されています。14 GBのRustビルドフォルダのコピー時間が約2分から約20秒に短縮されたと報告されています。さらに、通常の新しいworktreeでは約68秒かかる初回ビルドが、わずか3〜4秒にまで短縮される可能性があります。
これらは著者による報告結果であり、macOSのAPFSやLinuxのbtrfs、XFSなど、reflinkをサポートするファイルシステムでの可能性を示しています。すべての環境で保証されるわけではありませんが、特に巨大なビルドキャッシュやnode_modulesディレクトリを扱う場合、CoWがコールドスタートを大幅に削減できることを示しています。
魔法を期待する前にファイルシステムを確認する
瞬時の結果を期待する前に、システムの能力を確認することが不可欠です。Copy-on-Write (CoW)（またはreflink）は、ファイルシステムと設定に依存します。APFSを搭載した多くのMacや、btrfs、XFSといったLinuxファイルシステムはこれをサポートしていますが、非対応の環境では従来の低速なコピーにフォールバックされます。
重要な点として、CoWはハードリンクや共有の可変ディレクトリとは異なります。一方のworktreeでファイルを変更しても、ファイルシステムは変更されたブロックのみを複製するため、もう一方のworktreeのファイルは影響を受けません。これにより、並列環境間で意図しない変更が勝手に反映されることを防ぎます。
その影響を真に理解するには、実際のプロジェクトやドライブでWorktrunkの wt step copy-ignored コマンドをテストすることをお勧めします。経過時間とディスク使用量の両方を測定してください。パッケージマネージャー、ビルドツールのキャッシュ、さらにはコピー対象を細かく制御するための .worktreeinclude 設定などが結果に影響を与える可能性があります。
例えば、14 GBのRustビルドフォルダーを通常の方法でコピーすると約2分かかり、さらに14 GBのディスク容量を消費します。reflinkを使用すると、これが約20秒に短縮され、追加のディスク容量は実質的にゼロになります。これにより、コールドビルド時間が約68秒からわずか3〜4秒へと劇的に短縮されます。Worktrunkを使用した並列AIエージェント向けのGitワークフロー最適化の詳細については、Worktrunk — Git worktree management for parallel AI agent workflowsをご覧ください。なお、これらの数値は例示であり、環境によって結果は異なります。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
高速な起動を安全かつ再現可能なものに
Worktrunkのライフサイクルフックに wt step copy-ignored を追加して自動化しましょう。これにより、新しいワークツリーが自動的に有用なキャッシュを継承できるようになります。ただし、.worktreeinclude ファイルを使用して、コピーする無視対象のパスを明示的に指定してください。例えば、Rustプロジェクトなら target/ を、JavaScriptなら node_modules/ を含め、一時的なログファイルなどは除外するように設定します。
パスは慎重に選択してください。..env ファイルには機密情報が含まれていることが多いため、通常はコピーすべきではありません。また、キャッシュや生成された成果物は古い場合や環境固有のものである可能性があり、デバッグが困難な問題を引き起こす恐れがあります。無視されたすべてのファイルが共有して安全、あるいは有益とは限らないため、慎重に選択してください。
この最適化は慎重に導入してください。まずは単一のワークツリーで試してみましょう。適切な分離とビルドの正確性を確認してください。新しいワークツリーのコールドスタートを完全にクリーンなセットアップと比較してベンチマークを行い、Rustのビルドが68秒から3〜4秒に短縮されるといった劇的な高速化を確認してください。
検証が完了したら、チームのエージェントワークフロー用にコピー手順を自動化します。これにより一貫性が保たれ、ほぼ瞬時のワークツリープロビジョニングのメリットを最大限に活用でき、コールドスタートをウォームで生産的な開始へと変えることができます。
よくある質問
Worktrunkのcopy-ignoredコマンドは何をしますか？
既存のワークツリーからgitignoredファイルを新しいワークツリーにコピーします。ファイルシステムがサポートしている場合は、copy-on-write（書き込み時コピー）を使用します。
copy-on-writeはすべてのドライブで機能しますか？
いいえ。ファイルシステムとプラットフォームのサポート状況に依存します。APFS、btrfs、および一部のXFS構成はreflinkをサポートしていますが、それ以外の場合はコピーにより多くの時間とディスク容量が必要になることがあります。
別のワークツリーに .env ファイルをコピーしても安全ですか？
同じ機密情報や設定がその環境でも適切である場合にのみ安全です。何を含めるかを検討し、信頼できないプロジェクトやエージェントと認証情報を共有することは避けてください。
このコマンドの使い方は？
Worktrunkをインストールし、ワークツリーのセットアップの一部として wt step copy-ignored を実行します。現在のオプションや設定については、Worktrunkのドキュメントを確認してください。