機能開発のブランチで手を動かしている最中に、Slack に「本番でエラーが出ている」と緊急の連絡が入る。仕掛かりの変更を git stash で退避し、main に checkout し直し、依存を入れ直してビルドして、ようやく調査を始める——受託で複数案件・複数ブランチを抱えていると、この「切り替え」を一日に何度も繰り返すことになります。切り替えのたびに node_modules の再インストールや再ビルドが走り、stash の積み忘れで変更を見失う事故も起きる。作業そのものより、作業を切り替えるコストのほうが重い、という状態です。
GitHub Blog が「git worktree とは何か、なぜ使うべきか」で改めて取り上げたとおり、この切り替えコストは git worktree でかなり減らせます。git worktree は、一つのリポジトリから複数の作業ディレクトリを同時にチェックアウトできる仕組みです。本記事では、受託の並行開発で worktree がどう効くのか、そして導入時にどこでつまずくのかを、開発現場の立場から整理します。
なぜ checkout の切り替えがこんなに重いのか
git checkout（あるいは git switch）でブランチを移ると、作業ディレクトリの中身がそのブランチの状態に丸ごと書き換わります。これ自体は Git の正しい挙動ですが、現代の開発では副作用が重い。
ひとつは、ビルド成果物と依存の作り直しです。ブランチによって package.json やロックファイルが違えば、切り替えのたびに依存を入れ直す必要があります。フロントエンドのビルドキャッシュも無効になり、開発サーバーを立て直すことになる。
ふたつめは、仕掛かり変更の退避です。コミットしていない変更があると、そのままでは checkout できません。stash で逃がすことになりますが、stash は積み重なると「どれがどの作業のものか」が分からなくなり、戻し忘れの温床になります。
みっつめは、頭の切り替えです。同じディレクトリの中身が別物になるため、エディタで開いていたファイルがコンテキストごと変わり、「さっきまで何をしていたか」を思い出すのに時間がかかります。
git worktree は、この三つをまとめて回避します。ブランチごとに別々のディレクトリを持てるので、緊急修正用のディレクトリと機能開発用のディレクトリが同時に存在でき、切り替えは「フォルダを移るだけ」になります。
git worktree の基本 — 一つのリポジトリ、複数の作業場所
worktree は、既存のリポジトリに「もう一つの作業ディレクトリ」を生やすイメージです。たとえば、緊急修正用に main を別ディレクトリで開くなら、こう書きます。
# いまのリポジトリから ../project-hotfix に main を展開する
git worktree add ../project-hotfix main
# 新しいブランチを切りつつ別ディレクトリで開く
git worktree add ../project-feature-x -b feature/search-improveこれで ../project-hotfix と ../project-feature-x が、それぞれ独立した作業ディレクトリとして存在します。.git の実体は元のリポジトリで共有されるため、フェッチした履歴やリモート設定は全ディレクトリで共通です。stash も不要で、機能開発の手を止めずに別ディレクトリで緊急対応に入れます。
使い終わったら、ディレクトリを消すのではなく worktree として片付けます。
git worktree remove ../project-hotfix # 作業ディレクトリを除去
git worktree list # 今ある worktree を一覧注意点として、同じブランチを二つの worktree で同時にチェックアウトすることはできません。これは矛盾した状態を防ぐための制約で、ブランチは worktree ごとに別であるのが前提です。
受託の「並行案件」にどう効くか
受託では、一つのプロジェクトに対して「リリース済みの本番ブランチ」「進行中の機能ブランチ」「レビュー依頼が来た同僚のブランチ」が同時に存在するのが普通です。これを worktree で分けると、それぞれの作業が干渉しなくなります。
| ありがちな場面 | worktree なしの動き | worktree ありの動き |
|---|---|---|
| 開発中に緊急バグ修正が入る | stash → checkout → 再ビルド | 別ディレクトリで即対応、本作業はそのまま |
| 同僚の PR をローカル確認 | 自分の変更を退避して checkout | 確認用ディレクトリで開くだけ |
| 長期ブランチと短期修正の並行 | 行き来のたびに環境再構築 | 各ディレクトリで環境を維持 |
特に効くのが、長時間かかるビルドやテストを別ディレクトリで走らせながら、本体で別の作業を続けられる点です。CI を待つあいだ手が止まる、という無駄が減ります。AIコーディングエージェントに別ブランチの作業を任せる運用とも相性がよく、エージェント用の作業ディレクトリを分けておけば、自分の手元の変更を汚さずに並行で進められます。エージェントを絡めた開発フローの組み方は、Claude Code を使った開発ワークフローの記事で扱った考え方と組み合わせると効果が出ます。
受託で導入したときの落とし穴
弊社がチームに入って開発体制を立て直したある業務システムの案件（社名は伏せます）では、メンバーが全員、機能開発と本番障害対応を同じディレクトリで切り替えており、緊急対応のたびに「仕掛かりを stash して、戻すときにコンフリクト」という事故が月に数回起きていました。
私たちは、各メンバーに「機能開発用」と「本番対応用」の二つの worktree を持つ運用へ切り替えました。緊急対応は本番用ディレクトリで完結させ、機能開発の手元はいっさい触らない。これで stash の戻し忘れによる事故が止まりました。
この移行で一番つまずいたのは、環境設定ファイルとビルドキャッシュの扱いでした。.env のように Git 管理外のファイルは worktree 間で共有されないため、新しいディレクトリを作るたびに置き直す必要があります。私たちは worktree 作成時に必要ファイルをコピーするセットアップスクリプトを一本用意し、これを解決しました。また node_modules も worktree ごとに別になるため、ディスク使用量は増えます。ストレージが厳しい環境では、依存をディレクトリ間で共有する仕組み（pnpm のストアなど）と組み合わせる判断が要ります。リポジトリと依存の構成そのものを整理する観点は、モノレポで依存のズレを断つ記事で扱った内容とあわせて検討すると、並行開発と依存管理を一貫して設計できます。「同じブランチを二重に開けない」制約も含め、worktree は万能ではなく、並行作業が多い案件でこそ効く道具だと割り切るのが現実的です。
どこから着手するか
まず、自分が一日にブランチを何回切り替えているかを意識してみるのが出発点です。緊急対応や PR レビューのたびに stash と再ビルドを繰り返しているなら、その作業をもう一つの worktree に逃がすだけで、切り替えコストはほぼ消えます。最初は「緊急対応専用ディレクトリ」を一つ追加するところから始め、.env のコピーだけ仕組み化すれば、すぐに効果を体感できます。
並行案件の切り替えで開発が遅い、緊急対応のたびに仕掛かりを壊している、チームの開発フローを整えたい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行の開発体制を拝見し、worktree を含むワークフローの整備から、CI・レビュー運用の見直しまでお手伝いします。
