このような経験はありませんか？複雑な新機能を開発している最中に、突然緊急のバグ修正が入り、すぐに対応しなければならなくなったこと。
ブランチを切り替えるために、不本意ながら git stash を実行して作成途中のコードを一時退避します。バグ修正後に元のブランチへ戻り、慎重に git stash pop を行いますが、時にはコードコンフリクトという悪夢に直面することもあります。
実は Git には、この課題を根本から解決する強力な機能が以前から備わっています。それが Git Worktree です。
煩雑な切り替えや Stash と決別し、Worktree でマルチスレッド開発を実現する
本記事では、Git Worktree の仕組みと実践的な活用方法を分かりやすく解説します。
Git Worktree と Git Branch の違いとは？
Git Worktree を理解するために、まずは Git Branch との違いを整理しましょう。
バージョン管理を本を読む作業に例えてみます：
Commitは 本の版・バージョンBranchは 特定のページに挟んだ「しおり」Worktreeは 本を開いて作業する「作業デスク」
従来の方法では、作業デスクは1つしかありませんでした。しおりを切り替えるたびに、机の上の作業中の書類をすべて片付けるか引き出しに隠す必要がありました（これが git stash です）。
一方、Git Worktree を使えば、複数の 独立した作業デスク を同時に所有できます。
| 比較項目 | Git Branch | Git Worktree |
|---|---|---|
| ワークスペースの概念 | 単一の物理作業ディレクトリを共有 | 複数の独立した物理作業ディレクトリを所有 |
| 切り替えのコスト | コミット、Stash、または一時退避が必要 | Stash 不要で、ディレクトリを移動するだけ |
| 分離と安全性 | 未コミットファイルによる衝突や残留リスク | ディレクトリが完全分離し、変更が相互に干渉しない |
| 履歴管理 | Git Commit 履歴とブランチを共有 | Git Commit 履歴とブランチを共有 |
各 Worktree のカレントブランチ、ステージングエリア、未コミットの変更は完全独立していますが、すべての Commit 履歴とブランチ情報は共有 されます。
Branch はバージョンしおり、Worktree は物理作業デスク
これにより、タスクを切り替える際は別のフォルダを開くだけで済み、現在の開発状態に手を加える必要が一切なくなります。
Git Worktree の基本的な使い方
実際のプロジェクトに Git Worktree を導入する場合、適切なディレクトリ設計を行うことで開発がよりスムーズになります。
元々 git clone したプロジェクトディレクトリを清潔な main 本部として保持し、新しく作成する Worktree ディレクトリはプロジェクトの外側（例: ../my-app-worktrees）に配置することを推奨します。これにより、開発ツールの再帰スキャンエラーを防げます。
よく使うコマンドフローは以下の通りです：
| フロー | コマンド |
|---|---|
| 1. 新しい Worktree と新しいブランチを同時に作成 | git worktree add ../my-app-worktrees/feature-login -b feature-login |
| 2. 現在のすべての Worktree 一覧を確認 | git worktree list |
Git Worktree は、AI Agent の開発タスク管理にも最適です。
AI Agent に専用の Worktree ディレクトリを割り当てて自由に変更やテストを行わせる一方で、人間の開発者は別の Worktree でコードレビューや検証を並行して実施できます。
AI Agent に独立した Worktree を与え、AI 開発と人間によるレビューを並行処理する
双方がそれぞれの物理ディレクトリで作業するため、安全かつ明確に進行できます。
開発完了後のマージと安全なクリーンアップ方法
独立した Worktree での作業が完了した後、成果物をマージして整理するにはどのようにすればよいでしょうか？
重要な概念を覚えておきましょう：Worktree ディレクトリ自体をマージするのではなく、実際にマージするのは Branch ブランチ です。
main の作業デスクディレクトリに戻り、対応する機能ブランチに対して git merge を実行するだけで統合が完了します。
クリーンアップは以下の標準的な2ステップ手順で行います：
| ステップ | コマンド |
|---|---|
| 1. Worktree の物理ディレクトリを削除 | git worktree remove ../my-app-worktrees/feature-login |
| 2. 完了した機能ブランチを削除 | git branch -d feature-login |
先に Worktree ディレクトリを削除し、次に Branch ブランチを削除する
クリーンアップの際は、ファイルエクスプローラーでフォルダを直接手動削除するのではなく、必ず git worktree remove コマンドを使用してください。
Git Worktree 使用時の注意点と落とし穴
Git Worktree は非常に便利ですが、使用時に注意すべきポイントがいくつかあります。
落とし穴 1: 未コミットの変更が消失するリスク
Worktree を削除しても Branch 自体は消えませんが、未コミットの変更が残っている状態で Worktree ディレクトリを強制削除すると、それらの変更は失われてしまいます。
落とし穴 2: ブランチの重複チェックアウトのコンフリクト
Git の保護機能により、同じ Branch を複数の Worktree で同時に Checkout することはできません。すでに使用中のブランチを別の Worktree で切り替えようとすると、Git がエラーを出力してブロックします。
Worktree を強制削除すると、未コミットの変更が失われる
これらの特性と原則を押さえておけば、トラブルを未然に防ぐことができます。
まとめ
Git Worktree を導入することで、煩わしいブランチ切り替えや git stash の運用から解放され、真のマルチスレッド開発が実現します。
緊急のバグ対応、複数機能の同時開発、AI Agent へのタスク割り当てを行う際は、ぜひ新しい作業デスクを開いてみてください！