機能開発の途中でホットフィックスの対応を頼まれたとき、git stash で変更を退避してからブランチを切り替えて…という作業に手間を感じたことはないでしょうか。
git worktree を使うと、現在の作業ディレクトリをそのままにしたまま、別のディレクトリで別ブランチの作業を並行して進められます。stash で退避する必要がなく、コンテキストの切り替えが最小限で済むため、割り込み作業が発生しやすい開発現場で特に役立つコマンドです。
この記事では、git worktree の基本概念から実践的な使い方、注意点、よくある質問までを順番に説明します。
この記事でわかること
git worktree とは
git worktree は、1つの Git リポジトリから複数の作業ディレクトリ（ワークツリー）を同時に開ける機能です。Git 2.5（2015年リリース）から利用できます。
通常、1つのリポジトリには1つの作業ディレクトリしか持てません。ブランチを切り替えるたびに git switch や git checkout を実行し、必要に応じて git stash で作業中の変更を退避する必要があります。git worktree を使うと、この切り替えなしに別ブランチの作業ディレクトリを追加できます。
リポジトリを git clone で複数コピーする方法と比べると、.git 配下のオブジェクト情報（コミット履歴、ブランチ情報など）をすべてのワークツリーで共有します。そのため、ディスクの重複使用がなく、一方のワークツリーで作成したコミットをもう一方からすぐに参照できます。
よく使うコマンド一覧
| コマンド | 説明 |
|---|---|
git worktree add <パス> <ブランチ> | 既存ブランチを指定して作業ディレクトリを追加する |
git worktree add -b <新ブランチ> <パス> | 新規ブランチを作成しながら作業ディレクトリを追加する |
git worktree list | 現在のワークツリー一覧を表示する |
git worktree remove <パス> | 作業ディレクトリを削除する（ブランチは残る） |
git worktree prune | 不要になった参照をクリーンアップする |
git worktree lock <パス> | ワークツリーを誤削除から保護する |
手順1：現在のワークツリーを確認する
まず git worktree list で現在の状態を確認します。
ターミナルで以下のコマンドを実行します。
git worktree list実行後、次のような出力が表示されます。
/home/user/myproject a1b2c3d [feature-a]最初の列がディレクトリパス、2列目が HEAD コミットのハッシュ、3列目が現在チェックアウトしているブランチ名です。
手順2：新しい作業ディレクトリを追加する
既存ブランチを使う場合
main ブランチを ../hotfix-bug ディレクトリにチェックアウトします。
git worktree add ../hotfix-bug main実行後、../hotfix-bug ディレクトリが作成され、main ブランチがチェックアウトされた状態になります。
新規ブランチを作りながら追加する場合
-b オプションを使うと、ブランチの作成とワークツリーの追加を同時に行えます。
git worktree add -b hotfix/critical-bug ../hotfix-bug mainこのコマンドは main を起点に hotfix/critical-bug ブランチを新規作成し、../hotfix-bug ディレクトリにチェックアウトします。
手順3：追加したワークツリーで作業する
cd コマンドで追加したディレクトリに移動します。
cd ../hotfix-bug移動後は通常のリポジトリとまったく同じように作業できます。
# バグを修正してコミット
git add .
git commit -m "fix: クリティカルなバグを修正"コミット後、元の作業ディレクトリに戻ります。
cd ../myproject元の feature-a ブランチはそのままの状態で残っており、ここから作業を再開できます。
手順4：ワークツリーを削除する
作業が完了したら git worktree remove でディレクトリを削除します。
git worktree remove ../hotfix-bugコミットされていない変更が残っている場合はエラーになります。その場合は変更をコミットするか、--force オプションを付けて強制削除します。
# 強制削除（未コミットの変更は失われます）
git worktree remove --force ../hotfix-bugブランチ自体は削除されません。ブランチも不要な場合は別途 git branch -d で削除します。
git branch -d hotfix/critical-bug実践例：機能開発中にホットフィックスが割り込んだ場合
より具体的なシナリオで流れを確認します。
現在 feature-a ブランチで開発中とします。
/home/user/myproject a1b2c3d [feature-a] ← 現在ここで作業中本番環境でバグが見つかり、main ブランチから修正する必要が生じました。
ステップ 1：ホットフィックス用のワークツリーを追加
# 元のディレクトリ（feature-a）はそのまま
git worktree add -b hotfix/bug-001 ../hotfix-bug-001 mainステップ 2：ホットフィックスのディレクトリで修正・コミット
cd ../hotfix-bug-001
# バグを修正する
git add src/fix.js
git commit -m "fix: ログイン時のセッション切れを修正"
git push origin hotfix/bug-001ステップ 3：元の機能開発に戻る
cd ../myproject
# feature-a ブランチは変更されていないため、そのまま作業を再開できるステップ 4：ワークツリーを削除してブランチを整理
git worktree remove ../hotfix-bug-001
git branch -d hotfix/bug-001注意点
同じブランチを複数のワークツリーで同時にチェックアウトできない
1つのブランチは同時に1つのワークツリーにしかチェックアウトできません。別のワークツリーで使用中のブランチを再度追加しようとするとエラーになります。
fatal: 'feature-a' is already checked out at '/home/user/myproject'開発サーバーのポート競合に注意
複数のワークツリーでそれぞれ npm run dev を実行すると、デフォルトの 3000 番ポートが競合します。.env.local や起動オプションでポート番号を変えて対応する必要があります。
# 例：ポートを変えて起動
npm run dev -- --port 3001ワークツリーを増やしすぎない
ワークツリーが増えるほど管理が煩雑になります。git worktree list で定期的に不要なワークツリーが残っていないか確認する習慣をつけておくとよいでしょう。
削除前に変更をコミットしておく
git worktree remove は未コミットの変更がある場合にエラーになります。削除前に変更をコミットするか、stash で退避しておきます。
元に戻す方法
ワークツリーの削除は git worktree remove <パス> を実行するだけです。
git worktree remove ../hotfix-bug追加した作業ディレクトリが削除されますが、ブランチとコミット履歴は元のリポジトリにそのまま残ります。ブランチも不要であれば別途削除します。
git branch -d hotfix/bug-001不要なワークツリーの参照が .git/worktrees に残ってしまった場合は git worktree prune でクリーンアップできます。
git worktree pruneよくある質問
git clone で複数コピーを作るのと何が違うの？
git clone で複数のコピーを作ると、それぞれがリモートリポジトリとは独立した .git ディレクトリを持ちます。コミット履歴やオブジェクトが重複するためディスク使用量が増え、一方のコピーでの変更をもう一方に反映するにはプッシュ・プルが必要です。
git worktree はオブジェクトストアを共有するため、ディスク使用量が少なく、ブランチを即座に参照し合えます。
| 比較項目 | git worktree | git clone（複数コピー） |
|---|---|---|
| .git の共有 | 共有する | 共有しない |
| ディスク使用量 | 少ない（差分のみ） | 多い（オブジェクトが重複） |
| ブランチの参照 | すぐに可能 | push/pull が必要 |
| 向いているシーン | 短期間の並行作業 | 長期間の独立した開発 |
git stash とどう使い分ければいい？
git stash は現在のブランチを維持したまま変更を一時退避するためのコマンドです。少しだけ別の作業をして戻る場合や、「試してみたけどやっぱり戻す」といった場面に向いています。
git worktree は別ブランチで本格的な作業が必要な場合に使います。ホットフィックスのように変更をコミットしてプッシュまで行う場合や、作業時間が長くなりそうな場合は git worktree のほうが安全です。
詳しい stash の使い方は「git stash の使い方」を参考にしてください。
AIエージェントとの組み合わせは？
Claude Code や Cursor、GitHub Copilot Agent など、ターミナルでコードを自律的に編集する AIエージェントを複数タスク並行で動かす際にも git worktree は役立ちます。
たとえば、1つのワークツリーではエージェントに機能追加のコードを書かせながら、別のワークツリーではエージェントにテストを追加させるといった並行実行が可能です。それぞれのワークツリーで独立したブランチが動いているため、エージェントの変更が互いに干渉しません。
AIエージェントのタスクが長時間かかる場合でも、人間側は別のワークツリーで通常の開発を続けられます。
まとめ
git worktree を使うと、ブランチを切り替えることなく別ブランチの作業を並行して進められます。
ホットフィックスのような割り込み作業が発生したとき、stash を使わずにコンテキストをそのまま保持できるのが最大のメリットです。AIエージェントとの組み合わせも含め、並行作業が多い開発スタイルで活用してみてください。
関連記事：
