【Git】worktreeの使い方！ブランチ切り替え不要で並行開発する方法

PR Amazonのアソシエイトとして、ITナレッジライフは適格販売により収入を得ています。

記事の文字数：5,103

Git worktreeの使い方を初心者にもわかりやすく徹底解説！ブランチ切り替えやgit stashを行わずに、複数ブランチを別ディレクトリで同時に作業できる便利な仕組み、add・list・remove等の基本コマンドから実務での注意点まで網羅します。

公開日 2026/11/14

最終更新 2026/11/14

Gitユーザにお勧めの本 ↗

初心者向け

いちばんやさしいGit&GitHubの教本第3版人気講師が教えるバージョン管理＆共有入門「いちばんやさしい教本」シリーズ

難易度

実用性

読みやすさ

こんな人におすすめ： Gitをこれから使い始める人、挫折した経験がある人

とにかく挫折しない丁寧な解説。チーム開発での基本的な流れを確実にマスターできます。

Amazon 🔴 楽天

改訂2版わかばちゃんと学ぶ Git使い方入門

難易度

実用性

読みやすさ

こんな人におすすめ：マンガで楽しくGitを学びたい人

漫画形式で視覚的にイメージしやすい。Git特有の難しい用語も、物語を通して自然に理解できます。

Amazon 🔴 楽天

独習Git

難易度

実用性

読みやすさ

こんな人におすすめ： Gitの内部構造や高度な機能を学びたい人

コマンドの裏側で何が起きているかを丁寧に解説。プロとしてGitを使いこなすためのバイブルです。

Amazon 🔴 楽天

📚 ITエンジニア向けおすすめ技術書・関連書籍まとめはこちら

機能開発の途中で「本番環境で緊急バグが発生したのですぐに修正してほしい」と依頼されたり、プルリクエストのレビューのために別のブランチをローカルで動かしたくなったりした経験はありませんか？

従来は git stash で作業を一時退避してからブランチを切り替えるか、リポジトリを別の場所に再度 git clone して対応することが一般的でした。しかし、stash の適用忘れやコンフリクトのリスク、別ディレクトリへの clone による管理負荷やディスク消費の増加といった課題がつきまといます。

そんな悩みを解消するのが、GitGit [ギット]ソースコードの変更履歴を管理する分散型バージョン管理システム 2.5 で導入された git worktree です。ひとつのローカルリポジトリを共有しながら、異なるブランチを別ディレクトリとして同時に展開し、並行して作業やビルドを進められます。

本記事では、git worktree の基本的な使い方から、実務で役立つ運用テクニック、注意点まで実際のコマンド実行例を交えて詳しく解説します。

1. Git worktree とは？（特徴とメリット）

git worktree は、 1つの Git リポジトリの管理領域を共有しながら、複数の作業ディレクトリ（作業ツリー）を同時にチェックアウトできる機能 です。

worktree を使わない通常の Git 運用では、1つの作業ディレクトリで1つのブランチをチェックアウトして作業します。ブランチを切り替える際、未コミットの変更が切り替え先のブランチと競合する場合は、そのまま切り替えられないため、変更をコミットするか、一時退避する必要があります。

これに対して git worktree を使うと、コミット履歴やオブジェクトなどは共有しつつ、各ワークツリーが独立した HEAD やインデックスを持つことができます。そのため、メインの作業ツリーとは別の独立したフォルダに異なるブランチを展開し、並行して作業を進められます。なお、追加したワークツリー内の .git はディレクトリではなく、メインリポジトリの管理領域を参照するファイルとして作成されます。

git stash や別ディレクトリへの clone との違い

複数作業を並行して進めるアプローチを比較してみましょう。

比較項目	git stash	別フォルダへの git clone	git worktree
作業の並行性	切り替えが必要（同時作業不可）	完全に独立して同時作業可能	完全に独立して同時作業可能
ディスク容量	最小限	独立したリポジトリを作成するため、管理領域が重複する場合がある	Git のオブジェクトや履歴を共有するため、効率的
コミット履歴の共有	同一リポジトリ内	別リポジトリのため、`fetch` / `pull` が必要	同じリポジトリの履歴・ブランチ情報を共有
ビルド・依存関係	切り替え時に再ビルドが必要	独立した成果物を保持可能	ディレクトリごとに成果物を保持可能

一時的な退避だけであれば git stash で十分なケースもありますが、開発サーバーを起動したまま別ブランチでバグ修正したい場合や、手元のビルド成果物を残しておきたい場合には、git worktree が非常に有効です。

ITナレッジライフ

【Git】git stashの使い方｜作業の退避・復元・削除コマンドを徹底解説

作業中の変更を一時的に退避できる「git stash」コマンドの基本的な使い方から、特定ファイルの退避、退避した作業の復元や削除、そしてよくあるトラブルシューティングまで徹底解説します。Gitでの作業効率を上げたい方必見です。

ITナレッジライフ

git diff 完全ガイド：差分確認からアーカイブまで詳しく解説

Gitの変更履歴を把握するにはgit diffコマンドを利用します。本記事では、git diffの基本的な使い方からブランチ間の比較、変更のアーカイブ方法まで詳しく解説します。さらに、視覚的に差分を確認できるツールや、実践的な活用シナリオも紹介します。

2. git worktree の基本的な使い方

日常的な開発で頻出する、ワークツリーの「追加」「確認」「削除」の3つの基本コマンドを見ていきましょう。

ワークツリーを追加する（git worktree add）

ワークツリーを追加するには git worktree add コマンドを使用します。

新しいブランチを作成して追加する場合

既存のブランチから派生させた新規ブランチを別ディレクトリにチェックアウトする場合、-b オプションを指定します。

1
git worktree add ../hotfix-login -b hotfix-login

1
Preparing worktree (new branch 'hotfix-login')
2
HEAD is now at 8f1f252 Initial commit

このコマンドを実行すると、現在のリポジトリの親ディレクトリ（../）に hotfix-login フォルダが作成され、新しく作成された hotfix-login ブランチがチェックアウトされた状態になります。

新しく作られたディレクトリに移動すれば、メインの作業ツリーに影響を与えることなく、独立してファイルの編集やコミットが可能です。

既存のブランチを指定して追加する場合

すでに作成済みのローカルブランチを作業ツリーとして展開する場合は、ディレクトリ名とブランチ名を指定します。

1
git worktree add ../feature-checkout feature-checkout

1
Preparing worktree (checking out 'feature-checkout')
2
HEAD is now at 8f1f252 Initial commit

リモートブランチを基に新しいローカルブランチを作成する場合は、-b オプションとリモート追跡ブランチを指定します。

1
git worktree add ../feature-checkout -b feature-checkout origin/feature-checkout

ブランチを作らず一時的に展開する場合（—detach）

レビューやテストだけを行いたい場合、新しいブランチを作成する必要はありません。--detach オプションを付けることで、指定したコミットをブランチに紐づけずに（Detached HEAD 状態で）チェックアウトできます。

1
git worktree add --detach ../review HEAD

1
Preparing worktree (detached HEAD 8f1f252)
2
HEAD is now at 8f1f252 Initial commit

一時的な動作確認や長時間のテストに便利です。

ワークツリーの一覧を確認する（git worktree list）

現在リポジトリに紐づいているワークツリーの一覧を確認するには、git worktree list を実行します。

1
git worktree list

1
/home/user/project/my-app            8f1f252 [main]
2
/home/user/project/feature-checkout  8f1f252 [feature-checkout]
3
/home/user/project/hotfix-login      8e3f8c0 [hotfix-login]

出力結果には、作業ディレクトリのパス、現在のコミットハッシュ、およびチェックアウトされているブランチ名が表示されます。一番上にはメインの作業ツリーが表示され、その下に追加したワークツリーが表示されます（上記は hotfix-login 側で1件コミットした後の例です）。

スクリプト等で機械的に処理したい場合は、--porcelain オプションを付けるとキー・バリュー形式で詳細情報を取得できます。

ワークツリーを削除する（git worktree remove）

追加したワークツリーでの作業（コミットやプッシュ）が完了し、不要になった場合は git worktree remove で安全に削除します。

1
git worktree remove ../hotfix-login

このコマンドを実行すると、指定した作業ディレクトリとその中のファイルが削除され、Git の管理情報からも登録が解除されます。

削除できない条件と強制削除
ワークツリー内に未コミットの変更（追跡対象ファイルの変更）や未追跡ファイルが残っている場合、またはサブモジュールが含まれている場合、通常の git worktree remove では削除できません。
強制的に削除したい場合は、-f（--force）オプションを付与します。ただし、未保存の変更や必要なファイルまで失われる可能性があるため、実行前に内容を確認してください。

なお、ワークツリーを削除しても、コミット済みの変更は共有リポジトリに残ります。ただし、ブランチ自体は自動的に削除されません。不要になったブランチを削除する場合は、別途以下のコマンドを実行します。

1
git branch -d hotfix-login

ただし、git branch -d はマージ済みのブランチのみ削除できます。また、他のワークツリーでチェックアウト中のブランチは削除できません。未マージの変更が残っている場合は、内容を確認したうえで必要に応じてマージするか、強制削除の -D オプションを使用します。

3. 実務で役立つ便利な運用テクニック

git worktree を実務でスムーズに使いこなすための応用コマンドとディレクトリ配置のコツを紹介します。

手動削除したワークツリーを整理する（git worktree prune）

git worktree remove を使わずに、GUIGUI [ジーユーアイ / グーイ]Graphical User Interface。グラフィカルな操作画面や rm -rf コマンドでワークツリーのディレクトリを直接削除すると、Git の管理情報（$GIT_DIR/worktrees/、通常は .git/worktrees/）に古い記録が残ることがあります。

このように、作業ディレクトリが存在しなくなったワークツリーの管理情報を整理するには、 git worktree prune を実行します。

1
git worktree prune -v

1
Removing worktrees/hotfix-login: gitdir file points to non-existent location

-v（--verbose）オプションを付けると、どのワークツリー管理情報が削除されたのかが画面に表示されるため安心です。なお、ワークツリーを削除したのではなく別の場所に移動した場合は、prune ではなく git worktree repair で関連付けを修復する必要があります。

誤削除を防ぐロック機能（git worktree lock / unlock）

ネットワークドライブやポータブルストレージ上のワークツリーなど、常にアクセスできるとは限らない作業ディレクトリにはロックを設定できます。

ロックすると、prune による管理情報の自動削除を防げるほか、通常の remove や move による操作も制限できます（ロックしたまま強制削除・移動するには -f を2回指定する必要があります）。

1
git worktree lock --reason "レビュー完了まで保持" ../feature-checkout

ロックを解除する際は unlock コマンドを使用します。

1
git worktree unlock ../feature-checkout

ディレクトリ配置のベストプラクティス

ワークツリーを作成する際、適当な場所に散らかしてしまうと後から管理が大変になります。実務では以下の2つのパターンのいずれかでディレクトリ構造を統一するのがおすすめです。

パターンA: 共通の親ディレクトリを設ける構成

リポジトリのクローン先をあらかじめ my-project/main のように階層化しておき、並列にワークツリーを作成する構成です。

1
my-project/
2
├── main/              # メインの作業ツリー（mainブランチ）
3
├── hotfix-login/      # 緊急修正用ワークツリー
4
└── feature-payment/   # 新機能開発用ワークツリー

パターンB: メインリポジトリ内に専用フォルダを作成する構成

リポジトリ直下に .worktrees フォルダを作成し、その中にワークツリーを展開する構成です。

.worktrees/ をメインリポジトリの .gitignore に追加しておくことで、ワークツリーのディレクトリがメインの作業ツリーで未追跡ファイルとして検出されるのを防げます。

1
echo ".worktrees/" >> .gitignore

1
git worktree add .worktrees/hotfix -b hotfix

ただし、各ワークツリーは独立した作業ディレクトリとして動作するため、.gitignore はそれぞれの作業ツリーごとに適用されます。また、各ワークツリーでは依存関係のインストールや環境設定ファイルの配置が個別に必要になるため、これらのセットアップ方法もあらかじめ決めておくとスムーズです。

4. Git worktree を使う際の注意点

非常に便利な git worktree ですが、利用時に気をつけたい制約やポイントがいくつかあります。

同一ブランチを複数ワークツリーで同時にチェックアウトする際の制限

Git では、作業内容の不整合を防ぐため、 通常はすでに他のワークツリーでチェックアウトされているブランチを、別のワークツリーで重ねてチェックアウトすることはできません 。

もし既にチェックアウト中のブランチを指定して git worktree add を実行すると、以下のようなエラーメッセージが表示されます。

1
fatal: 'main' is already checked out at '/path/to/my-app'

同じブランチをベースに作業したい場合は、新しいブランチ名を指定して分岐させるか、不要になった元のワークツリーを削除してからチェックアウトしてください。

ただし、--force（-f）オプションを指定すれば強制的にチェックアウトできます。複数のワークツリーで同一ブランチを扱うことは管理上の問題が発生しやすいため、通常の運用では避けることをおすすめします。

未追跡ファイルや環境設定ファイル（.env）は引き継がれない

ワークツリーは、指定したコミットの内容を基に新しい作業ディレクトリを作成します。そのため、元のワークツリーに存在する未追跡ファイルや、.gitignore で除外されているファイル（.env や node_modules など）は、新しいワークツリーには自動でコピーされません。

Git で追跡されていない「未追跡ファイル」には、.gitignore によって無視されているファイルも含まれます。ただし、.gitignore はすでに Git で追跡されているファイルには影響しません。そのため、追跡対象のファイル（過去にコミットされた .env など）であれば、.gitignore に追加されていても新しいワークツリーにチェックアウトされます。

Node.js プロジェクトなどの場合、新しいワークツリーに移動した後にパッケージのインストール（npm install 等）や、環境変数ファイル（.env）の配置が必要になる点に注意しましょう。