[AI書房] 第30章 Gitワークツリー: 安全な並列開発の秘訣
Claude Code完全攻略
第8部
第30章 Gitワークツリー: 安全な並列開発の秘訣
金京鎮
緊急の電話
新しい決済機能の開発中です。コードの半分ほど記述したところで、Slack の通知が鳴りました。運用サーバーでログインバグが発生したという緊急報告です。今すぐ修正する必要があります。
問題は、現在作業中のコードがまだ完成していないことです。コミットするには未完成ですが、変更点を捨てることもできません。緊急修正のためにブランチを切り替えるには、現在の作業をどこかに一時保存する必要があります。git stash で保存し、ブランチを切り替え、修正し、再び元のブランチに戻って stash を取り出す……これは複雑です。ミスが入り込む余地が至る所にあります。
Git Worktree はこの状況を根本的に解決します。
ワークツリーとは何か
Git の基本構造では、1 つのリポジトリは 1 つの作業ディレクトリに紐付いています。そのディレクトリ内では、一度に 1 つのブランチしかチェックアウトできません。別のブランチで作業するには、現在のブランチの変更を整理した上でブランチを切り替える必要があります。
ワークツリーはこの制約を打破します。1 つのリポジトリ内で複数のブランチを同時にチェックアウトできます。各ブランチは別々のフォルダに存在します。
例えてみましょう。従来の方式は机が 1 つしかない事務所のようなものです。プロジェクト A の書類を広げて作業している最中にプロジェクト B を行う必要が生じれば、A の書類をすべて片付けてから B の書類を取り出す必要があります。一方、ワークツリーは机を複数設置するものです。A の書類は最初の机にそのまま広げたままにし、2 つ目の机で B の作業を行います。各机は独立していますが、同じ事務所(リポジトリ)内にあります。
ワークツリーの基本的な使い方
ワークツリーを作成する Git コマンドは簡潔です。
このコマンドは、現在のリポジトリから hotfix/login-bug というブランチを ../hotfix-login 経路に新しい作業ディレクトリとしてチェックアウトします。既存の作業ディレクトリには影響を与えません。
これで 2 つのフォルダが用意されます。元のフォルダには開発中の決済機能のコードがそのまま残っており、新しいフォルダには緊急修正用のブランチがクリーンにチェックアウトされています。2 つのフォルダを行き来して作業でき、互いのファイルに影響を及ぼすことはありません。
ワークツリーのリストを確認するには:
作業が完了したワークツリーを削除するには:
実際にはフォルダごとコピーするわけではないため、ディスク使用量も効率的です。Git の内部データ(.git ディレクトリ)は共有され、各ワークツリーには対応するブランチのファイルのみがチェックアウトされます。
Claude Code のネイティブワークツリーサポート
Claude Code は Git ワークツリーをネイティブでサポートしています。Git コマンドを手動で入力する必要はありません。
この一行で、Claude Code が自動的にワークツリーを作成し、新しいブランチを作成して、そのワークツリー内で Claude Code セッションを開始します。Git ワークツリーの複雑なコマンド体系を知らなくても、ワークツリーの利点をそのまま享受できます。
もちろん、詳細な制御が必要な場合は、Git コマンドを直接使用することも可能です。Claude Code のネイティブサポートは利便性のためのものであり、Git の機能を制限するものではありません。状況に応じて両方の方法を組み合わせて使用すればよいのです。
複数セッションの運用:実戦シナリオ
ワークツリーの真価は、Claude Code と組み合わせたときに発揮されます。各ワークツリーで独立した Claude Code セッションを実行できるからです。
具体的なシナリオを描いてみましょう。
状況:電子商取引プラットフォームの開発中です。3 つの作業を同時に実行する必要があります。
実行手順:
ターミナル A で:
「ウィッシュリスト機能を実装してください。ユーザーが商品を追加・削除でき、リストを共有できる必要があります。」
ターミナルBで:
「決済ページUIをモバイルファーストで再設計してください。現在のデザインのスクリーンショットを参考にしてください。」
ターミナルCで:
「カート内の数量変更時に合計金額が更新されないバグを修正してください。」
3 つのセッションが同時に動作します。各セッションは自身のワークツリー内でのみファイルを修正するため、競合は発生しません。緊急修正が先に完了すれば、そのブランチをメインにマージし、残りの機能開発は継続します。
機能開発と緊急修正の並行処理
上記のシナリオにおける核心は、緊急修正が既存の開発作業を妨げない点にあります。
ワークツリーがなければどうなっていたでしょうか?ウィッシュリスト機能を半ばで中断し、変更をスタッシュするか未完了のコミットを作成し、ブランチを切り替え、バグを修正し、再び元のブランチに戻ってスタッシュを復元する必要があります。この過程でスタッシュの競合が発生したり、未完了のコミットが履歴を汚したりする可能性があります。
ワークツリーでは、こうした手間は一切不要です。ウィッシュリストの作業はその場に残ったままです。新しいターミナルを開き、新しいワークツリーでバグを修正します。完了したらワークツリーを削除します。ウィッシュリストの作業に戻る際、復元する必要も、切り替える必要もありません。元のターミナルでそのまま続行すればよいのです。
この安全性は、Claude Code を複数のセッションで実行する際に一層重要になります。人間が直接コードを作成する場合はミスを即座に認識できますが、AI エージェントがコードを作成する場合は、互いの作業が上書きされる事故が静かに起こり得ます。ワークツリーはこの事故を構造的に不可能にします。
ワークツリー管理の実践的アドバイス
ワークツリーを多数作成すると管理が必要になります。いくつかの実践的なヒントを整理します。
命名規則を定めましょう。feature-、hotfix-、refactor- といった接頭辞を一律に使用すれば、どのワークツリーが何の目的を持つのか一目で把握できます。
作業が完了したワークツリーは直ちに削除しましょう。放置すると、どのワークツリーがアクティブ状態なのか混乱が生じます。ブランチをメインにマージした後は、git worktree remove で綺麗に整理してください。
ワークツリーディレクトリの位置を一貫して決めておきましょう。プロジェクトフォルダと同じレベルの上位ディレクトリに置くか、プロジェクト内の特定のフォルダを指定するなど、ルールを決めておけば、ワークツリーを探すために迷うことがなくなります。
並列開発の安全網
ワークツリーは華やかな技術ではありません。Git の基本機能を拡張したものに過ぎません。しかし、この拡張が生み出す違いは大きいです。
一つのブランチで一つの作業しかできないという制約がなくなれば、作業のやり方は根本的に変わります。緊急修正のために機能開発を中断する必要もありません。複数のエージェントが同じプロジェクトで同時に作業しても、互いに邪魔し合うことはありません。実験的な試みは、別のワークツリーで自由に試すことができます。
このように自由に複数のセッションを運営するには、各セッションにどの程度の権限を与えるかという判断も必要です。エージェントにファイルを自由に修正させるのか、それとも毎回承認を得させるのか。自律性と統制のバランスを取る方法について、これから見ていきましょう。








