AI並行開発で再評価されるgit worktree

課題と仕組み

ブランチ切り替えの文脈切り替え負担
stashなしで作業を維持
別フォルダに並行作業環境を生成
編集中の状態を保持したまま修正

AI時代の必然

AIによる並行セッションの増加
Copilotアプリの既定動作
依存関係の重複と容量増
同一ブランチ二重利用の制限
詳細を読む

GitHubは6月16日、自社ブログでgitのworktree機能を解説しました。worktreeは一つのリポジトリから複数の作業フォルダを同時に切り出す仕組みで、ブランチを切り替えるたびにstashやファイル再読み込みが発生する従来の負担を解消します。AIによる並行開発が広がる今、改めて注目される技術だと位置づけています。

従来の開発では、作業中の機能を中断して緊急のバグ修正に移る際、変更を一時退避するstashやブランチの切り替えが必要でした。エディタの状態が崩れ、node_modulesの再インストールも求められるなど、文脈切り替えのコストは小さくありません。記事の筆者も、同じリポジトリを複数回クローンして回避していたと打ち明けています。

worktreeを使えば、コマンド一つで隣に新しい作業フォルダを作り、別ブランチをチェックアウトできます。元のエディタ画面はそのまま残るため、stashの衝突リスクがゼロになり、真の並行作業が可能になります。作業が終われば、そのフォルダを削除するだけで片付きます。

なぜ今なのでしょうか。GitHubは、AIが開発の進め方を変え、開発者がかつてないほど多数のセッションを並行させるようになったと指摘します。worktreeはGitHub Copilotアプリの既定動作であり、多くの最新ツールが採用しています。コードを書く文化からレビューする文化への移行も背景にあります。

一方で注意点もあります。各フォルダが依存関係を個別に持つためディスク容量を圧迫しやすく、不要なフォルダの削除やgitignoreへの追加といった管理も欠かせません。Gitは同一ブランチを二つのworktreeで同時にチェックアウトすることを、データ破損防止のため禁止しています。

結局worktreeを使うべきかは、開発スタイル次第だと記事は結論づけます。ブランチとstashの心的モデルを好む人もいれば、今後はworktree中心に切り替える人もいるでしょう。並行作業が日常化する経営者エンジニアにとって、選択肢として把握しておく価値のある手法です。