Git worktreeで複数ブランチの並行開発とコードレビューを効率化する実践ワークフロー
新機能の実装中に「本番環境で発生した緊急バグを今すぐ確認してほしい」「チームメンバーの Pull Request（PR）を手元で動かしてレビューしてほしい」と頼まれたとき、どのように対応しているでしょうか？
多くの方は git stash で作業途中の変更を退避してから git switch（または git checkout）でブランチを切り替えているかと思います。しかし、ブランチを切り替えると 「ビルドキャッシュが壊れる」「node_modules の再インストールが必要になる」「変更中のファイルを戻し忘れる」 といったストレスが頻繁に発生します。
この問題を根本から解決する Git 標準機能が git worktree（ワークツリー） です。本記事では、git worktree の基本操作から、散らからないディレクトリ構成のルールまで実践的に解説します。
1. git worktree とは何か？従来の git stash や複数 git clone との違い
通常の Git リポジトリには、1つの .git 管理ディレクトリに対して1つの作業ツリー（Working Tree）しか存在しません。これに対し git worktree を使うと、1つの .git オブジェクトデータベースを共有したまま、別々のブランチをチェックアウトした複数の作業ディレクトリを同時に展開できます。
| 比較項目 | git stash + git switch | リポジトリを別フォルダに再 clone | git worktree を使用 |
|---|---|---|---|
| 作業中ファイルの退避 | 毎回 stash / stash pop が必要 | 不要 | 不要（元のフォルダはそのまま維持） |
| ディスク容量・通信量 | 最小 | .git 履歴を丸ごと重複ダウンロード | 最小（.git 履歴は共有され差分のみ） |
| ローカルブランチ・コミットの共有 | 同一リポジトリなので共有 | push / fetch しないと共有されない | 即座に共有（同じ .git を参照） |
| 開発サーバーの同時起動 | 不可（1ブランチのみ） | 可能 | 可能（ポートを変えれば新旧比較も容易） |
たとえば、ポート 3000 で開発中の新機能ブランチを起動したまま、別ワークツリーのポート 3001 で main ブランチやレビュー対象ブランチを起動し、ブラウザを並べて挙動やUI差分を比較するといった使い方が一瞬で行えます。
2. git worktree の基本コマンド4つ（作成・確認・移動・削除）
覚えるべきサブコマンドは実質4つだけです。
2.1 新しいワークツリーを作成する (git worktree add)
現在のリポジトリが ~/Projects/my-app にある場合、隣に ~/Projects/my-app-hotfix というディレクトリを作り、同時に新しいブランチ fix/login-bug を切って展開するには以下のように実行します。
# 新規ブランチ fix/login-bug を作成しつつ、別ディレクトリへ展開（-b オプション）
git worktree add -b fix/login-bug ../my-app-hotfix mainすでにリモートやローカルに存在するブランチ（例：PRレビュー対象の feature/new-dashboard）を別ディレクトリに展開する場合は -b を外します。
# 既存ブランチを別ディレクトリへ展開
git worktree add ../my-app-review feature/new-dashboard2.2 展開中のワークツリー一覧を確認する (git worktree list)
現在どのパスにどのブランチが展開されているかは list でいつでも確認できます。
git worktree list出力例：
/Users/amori/Projects/my-app a1b2c3d [feat/user-profile]
/Users/amori/Projects/my-app-hotfix e4f5g6h [fix/login-bug]
/Users/amori/Projects/my-app-review 9i8j7k6 [feature/new-dashboard]2.3 作業完了後にワークツリーを削除する (git worktree remove)
緊急対応やPRレビューが終わったら、remove コマンドで安全に作業ディレクトリを削除できます（未コミットの変更がある場合は警告して保護してくれます）。
git worktree remove ../my-app-hotfixもし誤って Finder や rm -rf でディレクトリごと直接消してしまった場合でも、git worktree prune を実行すれば Git 内部の管理情報をきれいに掃除できます。
3. ディレクトリが散らからない実践的な配置パターン
git worktree を使い始めると、「親ディレクトリに my-app-xxx が大量に増えて散らかる」という悩みが出てきます。これを防ぐには、「専用サブディレクトリ方式（.worktrees/）」 が最も扱いやすくおすすめです。
.worktrees/ サブディレクトリ方式の設定手順
- プロジェクトの
.gitignore（または個人用の~/.config/git/ignore）に.worktrees/を追加します。# Global gitignore (~/.config/git/ignore) .worktrees/ - ワークツリーを作成する際は、すべて
.worktrees/<ブランチ名や用途>の下に配置します。git worktree add -b fix/header-layout .worktrees/fix-header-layout main
この方式には以下のメリットがあります。
- 親フォルダ（
~/Projects/）が一切汚れない。 - VS Code や Cursor、ターミナルから
.worktrees/fix-header-layoutを開くだけで独立したワークスペースとして機能する。 - 不要になったら
git worktree remove .worktrees/fix-header-layoutで即座に片付く。
4. node_modules や .env ファイルの引き継ぎを自動化するコツ
新しいワークツリーを作成した直後は、Git 管理外（.gitignore 対象）である .env（環境変数ファイル）や node_modules が存在しない真っさらな状態です。毎回手動で .env をコピーするのは手間なので、簡単なシェル関数を .zshrc に登録しておくと快適です。
# ~/.zshrc に登録：ワークツリー作成と同時に .env をコピーして移動する関数
gwt() {
local branch_name="$1"
local dir_name="${branch_name//\//-}"
local target_dir=".worktrees/$dir_name"
if [ -z "$branch_name" ]; then
echo "Usage: gwt <branch-name>"
return 1
fi
git worktree add -b "$branch_name" "$target_dir"
if [ -f ".env" ]; then
cp .env "$target_dir/.env"
echo "Copied .env to $target_dir"
fi
cd "$target_dir" || return
}さらに、パッケージマネージャーとして pnpm を採用しているプロジェクトであれば、コンテンツアドレス可能なグローバルストアからハードリンクが張られるため、新しいワークツリー上で pnpm install を実行しても数秒でセットアップが完了し、ディスク容量もほとんど消費しません。
5. よくある注意点：「同じブランチは2つのワークツリーで同時に開けない」
git worktree の仕様として、「すでにメインの作業ディレクトリでチェックアウト中のブランチ（例：main）を、別のワークツリーでも同時にチェックアウトすることはできない」 という制約があります（両方から同時にコミットされて状態が壊れるのを防ぐため）。
もし「手元の変更はそのままで、純粋な最新の origin/main の動作を確認したい」という場合は、ブランチ名ではなく origin/main を指定して Detached HEAD 状態で開くか、検証用の一時ブランチを切って開くことで解決できます。
# origin/main の最新状態を Detached HEAD で素早く確認する
git fetch origin
git worktree add --detach .worktrees/check-main origin/mainまとめ
git worktree を日常のワークフローに取り入れると、「ブランチ切り替えの待ち時間」と「stash の管理ミス」がゼロになります。特に複数タスクを並行して進めることが多いエンジニアや、AIコーディングエージェントに別ブランチで並行作業を任せる場面でも必須の技術ですので、ぜひ .worktrees/ 構成とあわせて活用してみてください。