git worktree は、1つのリポジトリに作業フォルダ（working tree）を複数つなげて、複数のブランチを同時に開いておけるようにする git のコマンドです。ブランチの切り替えのように1つのフォルダの中身を入れ替えるのではなく、ブランチごとに別のフォルダを持てます。
この記事は、ブランチの切り替えや git stash には慣れてきた人向けです。git worktree の考え方、ブランチの切り替え・stash・clone との違い、基本の使い方（add・list・remove・prune など）、使うときの注意点を、git の公式の文書などをもとに説明します。最後に、Claude Code・Codex・Cursor などの AI コーディングツールでの使われ方も短く紹介します（2026年10月時点）。
- git worktree は、1つのリポジトリに作業フォルダを複数つなげて、複数のブランチを同時に開いておく仕組みであること
- ブランチの切り替え・git stash・git clone との違い
- add・list・remove・move・lock・prune の使い方と、使える git の版
- 同じブランチは2か所で開けない、.gitignore 対象のファイルは入らない、フォルダを直接消したら prune、などの注意点
- Claude Code・Codex・Cursor などの AI コーディングツールでの worktree の使われ方（2026年10月時点）
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
\\ 3丁目オーナー開発アプリ！コンテンツ随時更新中 //
\\ これからITフリーランス //
git worktree とは？
git worktree は、1つのリポジトリにつながる作業フォルダ（working tree）を、複数まとめて管理するコマンドです。git の公式の文書は、1つのリポジトリが複数の作業フォルダを持てて、複数のブランチを同時にチェックアウトできる、と説明しています。チェックアウトとは、コミットの中身を作業フォルダに取り出すことです。
git worktree add で足した作業フォルダを linked worktree、git init や git clone でできた元の作業フォルダを main worktree と呼びます。linked worktree は 0 個以上つなげられます。この記事では、足した linked worktree を単に「worktree」、main worktree を「メインの作業フォルダ」と書きます。
足した worktree は、今のリポジトリにつながります。HEAD（いま開いている場所を指すもの）や index（ステージ）のような worktree ごとのファイルを除いて、すべてをリポジトリと共有します。共有されるものを、もう少し細かく見ると次のとおりです。
- ブランチなど
refs/で始まる参照は、全部の worktree で共有されます。HEAD などは worktree ごとに別々です。例外として、refs/bisect・refs/worktree・refs/rewrittenは共有されません。 - リポジトリの設定ファイル（config）は、既定ではすべての worktree で共有されます。
.git配下の config は、GitHub で複数アカウントを使い分ける方法の記事でも扱っています。 - 足した worktree のフォルダの中の
.gitは、フォルダではなくファイルで、元のリポジトリの.git/worktrees/<名前>を指しています。
ブランチの切り替え・stash・clone とは何が違う？
比べる相手ごとに、説明している公式の文書が違います。ブランチとの違いは VS Code の文書、stash との違いは git の文書、clone との違いは JetBrains と OpenAI Codex の文書の言い方で紹介します。
VS Code の文書は、使い分けを次のようにまとめています。
- ブランチ: 1つのフォルダの中で切り替えて、別々の開発の流れを分けておく。
- stash: コミットを作らずに、コミットしていない変更を脇に置いておく。
- worktree: 複数のブランチを、別々のフォルダで同時に開いたままにしておく。
ブランチの切り替えとの違い
VS Code の文書は、リポジトリ・ブランチ・worktree を次のように整理しています。
| 用語 | VS Code の文書の説明 |
|---|---|
| リポジトリ | 共有の履歴・ブランチ・タグ・リモート |
| ブランチ | リポジトリの履歴にあるコミットを指す、動く目印 |
| worktree | チェックアウトしたファイル・ステージ・コミットしていない変更を、自分で持つ作業フォルダ |
同じ文書は、worktree どうしは履歴を共有しますが、作業中のファイルとコミットしていない変更は共有しない、と書いています。たとえば、メインの作業フォルダでは main を開いたまま、別の worktree で feature/theme-toggle ブランチを開く、といった形です。
ブランチの切り替え（git switch）は、同じ作業フォルダの中身とステージを、指定のブランチに合わせて入れ替えます。手元の変更が失われる切り替えは、--discard-changes か --merge を付けない限り中止されます（git switch の文書）。JetBrains の文書は、worktree が1つだけの状態でブランチを替えるには、作業中のものをコミットするか stash する必要があると説明しています。worktree を足せば、複数のブランチを別々のフォルダで同時に開いておけます。
worktree での作業を main に戻すには、そのブランチのコミットをマージします（VS Code の文書の例）。マージの考え方は、Git MergeとRebaseの違いと使い分けの記事で説明しています。VS Code には、コミットしていない変更をメインの作業フォルダに移す Git: Migrate Worktree Changes... もあります。こちらはコミットをマージしません。
git stash との違い
git stash は、作業フォルダとステージの今の状態を記録して、作業フォルダをきれいな状態に戻すコマンドです（git stash の文書）。使い方は、git stash の使い方の記事で説明しています。
git の文書には、stash の代わりに worktree を使う例があります。作業フォルダが、新しいファイル・移したファイル・消したファイルなどで散らかっていて、どれにも手を付けたくない（stash で退避するのも避けたい）とき、一時的な worktree を作って急ぎの修正をします。終わったらその worktree を消して、元の作業の続きに戻ります。
例のコマンドは次のとおりです。例のブランチ名は master なので、自分のリポジトリのブランチ名に読み替えてください。
git worktree add -b emergency-fix ../temp master
pushd ../temp
git commit -a -m 'emergency fix for boss'
popd
git worktree remove ../temppushd ../temp でそのフォルダに移って修正とコミットをして、popd で元のフォルダに戻ります。最後に git worktree remove ../temp で worktree を消せば、元の作業の続きに戻れます。
git clone との違い
git clone は、リポジトリを新しく作ったフォルダに複製するコマンドです（git clone の文書）。JetBrains の文書は、clone はリポジトリを丸ごと複製するが、worktree は全部が同じ中央の .git の履歴を共有する、と説明しています。OpenAI Codex の文書も、それぞれの worktree はリポジトリの全ファイルのコピーを持つが、コミットやブランチなどの情報（.git フォルダ）は共有する、と書いています。
同じリポジトリを使っているので、worktree で作ったコミットは、push も fetch もしなくても、メインの作業フォルダからすぐ見えます。次は、ブランチ feature-c の worktree でコミットしたあと、メインの作業フォルダで実行した出力です（git 2.39.3 の出力）。
$ git log --oneline -1 feature-c
a87750a add c.txtこの worktree を git worktree remove で消したあとも、同じコミットが見えます。
git worktree の使い方（add・list・remove・move・lock）
git worktree には、add・list・lock・move・prune・remove・repair・unlock の8つのサブコマンドがあります。
| サブコマンド | はたらき |
|---|---|
add | worktree を足す |
list | worktree の一覧を出す |
remove | worktree を消す |
prune | フォルダが無くなった worktree の記録を消す |
move | worktree の場所を移す |
lock・unlock | 自動で prune されないようにする・その lock を外す |
repair | git を通さずに動かして切れたつながりを直す |
基本の流れは次のとおりです。
git worktree addで worktree を足す- その worktree のフォルダに移って、いつもどおり作業してコミットする
- 作業を main に戻すときは、そのブランチをマージする
- 使い終わったら
git worktree removeで消す
この節の出力例は、macOS の git 2.39.3（Apple Git-145）のものです。出力は英語です。git 本体の翻訳に日本語が含まれていないためです（翻訳ファイルの一覧、v2.56.0）。この記事でも英語のまま載せます。cat・ls・rm は macOS のターミナルで使うコマンドで、Windows での書き方は載せていません。例は、myapp というリポジトリのメインの作業フォルダ（main ブランチ）で実行した形で書きます。コミット番号（b2d6738 など）は、リポジトリごとに変わります。出力は、1 つの練習用リポジトリで流したものを節ごとに抜き出しています。節の順と流した順は同じではないので、一覧に出る worktree は節によって違います。
worktree を足す（add）
最も簡単な形は、パスだけを指定する git worktree add <パス> です。パスの最後の名前で新しいブランチを作って、そのブランチを開きます。たとえば git worktree add ../hotfix は、ブランチ hotfix を作って ../hotfix に開きます。../hotfix は、メインの作業フォルダ（myapp）と同じ階層にある hotfix フォルダという意味です（git 2.39.3 の出力）。
$ git worktree add ../hotfix
Preparing worktree (new branch 'hotfix')
HEAD is now at b2d6738 first commitほかの書き方は、次の3つです。
-b <新しいブランチ>を付けると、名前を決めて新しいブランチを作ります。起点（<commit-ish>）を省くと HEAD から作ります。すでにある名前だと-bは断られます。-Bは、すでにあるブランチを起点に付け直す（リセットする）ので、使うときは注意してください。- パスのあとにブランチ名を書くと、すでにあるブランチを開きます。
-d（--detach）を付けると、どのブランチにも属さない使い捨ての worktree（detached HEAD）を作ります。試しの変更やテスト向きです。今のブランチと同じコミットから始まります。
次の出力は、上から順にこの3つの書き方のものです（git 2.39.3 の出力）。
$ git worktree add -b feature-a ../myapp-feature-a
Preparing worktree (new branch 'feature-a')
HEAD is now at b2d6738 first commit
$ git worktree add ../myapp-existing existing-branch
Preparing worktree (checking out 'existing-branch')
HEAD is now at b2d6738 first commit
$ git worktree add -d ../experiment
Preparing worktree (detached HEAD b2d6738)
HEAD is now at b2d6738 first commitgit の文書の書式では、-b はパスの前に書きます。Claude Code と Gemini CLI の文書には、git worktree add ../project-feature-a -b feature-a のように、パスの後ろに書く例もあります。git 2.39.3 では、どちらの書き方でも通ります。この記事では、パスの前に書きます。
足した worktree のフォルダの中の .git は、フォルダではなくファイルです。中身は、元のリポジトリの .git/worktrees/<名前> を指す1行です（git 2.39.3 の出力。<LAB> は、練習用のフォルダまでの道筋を省いて書いたものです）。
$ cat <LAB>/hotfix/.git
gitdir: <LAB>/myapp/.git/worktrees/hotfixworktree の一覧を見る（list）
git worktree list で、worktree の一覧が出ます。メインの作業フォルダが先頭で、そのあとに足した worktree が並びます。各行は、フォルダのパス・コミット番号・開いているブランチの順です（git 2.39.3 の出力）。
$ git worktree list
<LAB>/myapp b2d6738 [main]
<LAB>/experiment b2d6738 (detached HEAD)
<LAB>/hotfix b2d6738 [hotfix]
<LAB>/myapp-existing b2d6738 [existing-branch]
<LAB>/myapp-feature-a b2d6738 [feature-a]
<LAB>/myapp-feature-b b2d6738 [feature-b]ブランチを持たない worktree には detached HEAD と出ます。lock されていれば locked、prune できる状態なら prunable と付きます。-v（--verbose）を付けると、locked や prunable の理由があれば、次の行に出ます。--porcelain はスクリプト向けの出力で、git の版や設定が変わっても形が変わりません。-z と組み合わせるのが推奨されています。
git branch の一覧では、ほかの worktree で開いているブランチに + が付きます。今のブランチは * です（git 2.39.3 の出力）。git branch の使い方は、Git コマンドのよく使う使い方を基本から学ぶ記事で説明しています。
$ git branch --list
+ existing-branch
+ feature-a
+ feature-b
+ hotfix
* mainworktree を消す（remove）
git worktree remove <worktree> で消します。<worktree> は、パスで指します（相対パスでも絶対パスでもかまいません）。パスの最後の部分がほかの worktree と重ならなければ、その部分だけでも指せます。
消せるのは、追跡していないファイルも、追跡中のファイルの変更も無い worktree だけです。変更があるものは --force を付けると消せます。メインの作業フォルダは消せません（git の文書）。次は、変更が残っている worktree と、メインの作業フォルダを消そうとしたときの出力です（git 2.39.3 の出力）。
$ git worktree remove ../myapp-feature-a
fatal: '../myapp-feature-a' contains modified or untracked files, use --force to delete it
$ git worktree remove .
fatal: '.' is a main working tree注意: worktree を消すと、その作業フォルダが消えます。--force を付けて消すと、コミットしていない変更も一緒に消えるので、消す前に中身を確かめてください。
lock されている worktree を消すには、--force を2回指定します。lock については、このあとの「外付けドライブなどに置くとき（lock・unlock）」で説明します。remove は、1回に1つの worktree だけを指定できます。2つ渡すと、使い方（usage）が表示されて止まります（git 2.39.3）。worktree を消してもブランチは消えません。このことは「注意点」で説明します。
worktree の場所を移す（move）
git worktree move <worktree> <新しいパス> で、worktree を別の場所に移します。メインの作業フォルダと、サブモジュールを含む worktree は、このコマンドでは移せません。lock されている worktree も、そのままでは移せません。
外付けドライブなどに置くとき（lock・unlock）
いつもはつながっていない外付けドライブや、ネットワーク上の共有フォルダに worktree を置いたときは、git worktree lock で lock しておくと、管理用のファイルが自動で prune されません。lock した worktree は、move も削除もできなくなります。--reason で、lock した理由を残せます。次は、git worktree add ../usb-wt で足した worktree を lock したときの出力です（git 2.39.3 の出力）。
$ git worktree lock --reason "on a USB drive" ../usb-wt
$ git worktree list --verbose
<LAB>/myapp b2d6738 [main]
<LAB>/experiment b2d6738 (detached HEAD)
<LAB>/myapp-feature-a b2d6738 [feature-a]
<LAB>/usb-wt b2d6738 [usb-wt]
locked: on a USB drive
$ git worktree remove ../usb-wt
fatal: cannot remove a locked working tree, lock reason: on a USB drive
use 'remove -f -f' to override or unlock firstgit worktree unlock で lock を外すと、prune・move・削除ができるようになります。git worktree add --lock なら、作ってすぐ lock できます。add のあとに lock するのと同じですが、作ってから lock するまでの間の隙が無い、と文書にあります。
つながりが切れたとき（repair）
git worktree repair は、git を通さずにメインの作業フォルダや worktree を動かして、つながりが切れたときに直すコマンドです。この記事では、出力例を載せていません。
使える git の版
使えるオプションには、git の版で違うものがあります。この記事の説明は、git-scm の git-worktree の文書（2.56.0 で最後に更新。2026-09-28）をもとにしています。古い版の文書は、https://git-scm.com/docs/git-worktree/<版> で開けます。
| 機能 | 使える版 |
|---|---|
git worktree add -d（--detach と同じ意味） | 2.29.0 から |
git worktree repair | 2.29.0 から |
git worktree list --porcelain と組み合わせる -z | 2.36.0 から |
git worktree add --orphan | 2.42.0 から |
--relative-paths・設定 worktree.useRelativePaths | 2.48.0 から |
--orphanは、空の worktree と、まだコミットの無い新しいブランチを作ります。git 2.39.3 では、unknown option のエラーになります。- コミットが1つも無いリポジトリで
git worktree addすると、git 2.39.3 ではfatal: not a valid object name: 'HEAD'というエラーになります。2.42.0 の版からの git の文書には、この場合は--orphanを付けたのと同じ扱い（まだコミットの無いブランチ）になる、と書かれています。 --relative-pathsは、worktree どうしを相対パスでつなぐオプションです。既定は絶対パスです（設定worktree.useRelativePathsの既定は false）。true にすると、古い git では扱えなくなります。
出典: 2.29.0・2.36.0・2.42.0・2.48.0 の git のリリースノート。
git worktree の注意点
worktree を使うときに、つまずきやすいところをまとめます。
同じブランチは2か所で開けない
同じブランチを、2つの worktree で同時に開くことはできません。ほかの worktree ですでに開いているブランチを add しようとすると、git は断ります。メインの作業フォルダで開いている main も同じです（git 2.39.3 の出力）。
$ git worktree add ../dup feature-a
Preparing worktree (checking out 'feature-a')
fatal: 'feature-a' is already checked out at '<LAB>/myapp-feature-a'
$ git worktree add ../dup2 main
Preparing worktree (checking out 'main')
fatal: 'main' is already checked out at '<LAB>/myapp'別の worktree の中で git switch する場合も同じです。ほかの worktree で開いていないブランチには切り替えられます。次は、wt-switch という worktree の中で実行した出力です（git 2.39.3 の出力）。この出力は、myapp-existing の worktree を消したあと（このあとの「remove は .gitignore 対象のファイルも消す」の操作のあと）のものです。このとき existing-branch は、どの worktree でも開いていません。
$ git switch existing-branch
Switched to branch 'existing-branch'
$ git branch --show-current
existing-branch
$ git switch main
fatal: 'main' is already checked out at '<LAB>/myapp'このエラーの文面は、git の版で違います。2.43.0 のリリースノートに、混乱を避けるために、ブランチが「使用中（in use）」であると言い換えた、とあります。上の出力は 2.39.3 なので、古い文面です。
- git 2.42 まで:
fatal: '<ブランチ>' is already checked out at '<パス>' - git 2.43.0 から:
fatal: '<ブランチ>' is already used by worktree at '<パス>'
--force を付けると、ほかの worktree で開いているブランチでも作れる、と git の文書にはあります。ただ、次の理由があるので、使うかどうかは慎重に考えてください。OpenAI Codex の文書は、この制限の理由を次のように説明しています。ブランチは1つの書き換わる参照（refs/heads/<名前>）です。複数の worktree が同時に開けるとすると、どの worktree の操作がブランチを更新するのかがあいまいになり、更新がぶつかる（race condition）おそれがあるためです。
VS Code と JetBrains の文書も、同じ制限を書いています。避け方は、そのブランチから別のブランチを作って使うか、detached HEAD で開くことです（JetBrains と Codex の文書）。
.gitignore 対象のファイル（.env など）は新しい worktree に入らない
新しい worktree には、.gitignore で外したファイル（.env や node_modules など）は入りません（VS Code の文書）。.gitignore については、.gitkeep と .gitignore の違いと使い分けの記事で説明しています。
次は、.gitignore に .env と node_modules/ を書き、.env をコミットしていない練習用リポジトリの出力です（git 2.39.3 の出力）。メインの作業フォルダ（myapp）には .env があり、hotfix の worktree には無いことが分かります。
$ ls -A <LAB>/myapp
.env
.git
.gitignore
README.md
$ ls -A <LAB>/hotfix
.git
.gitignore
README.md理由は、git worktree add が、新しいフォルダにコミットの中身を取り出す（checkout する）だけで、今のフォルダを写すわけではないからです。Claude Code の文書も、worktree は新しい checkout なので、メインのリポジトリにある .env や .env.local のような追跡していないファイルは無い、と書いています。
VS Code のエージェントの文書は、新しい worktree には、もとにするブランチのコミット済みのファイルが入り、メインの作業フォルダにあるコミットしていない変更や追跡していないファイルは、自動では入らないと説明しています。AI コーディングツールの文書には、この前提で、コピーや準備の仕組みが用意されています。次の節の表を見てください。
remove は .gitignore 対象のファイルも消す
逆に、worktree を消すときは、.gitignore 対象のファイルも一緒に消えます。VS Code の文書の注意（Caution）には、worktree を消すと、Git が変更なしと報告していても、そのフォルダの中の無視されているファイルも消える、とあります。
次は、.env（.gitignore 対象）だけが残っている worktree を、--force なしで消したときの出力です（git 2.39.3 の出力）。1つ目のコマンドは myapp-existing の中で、2つ目はメインの作業フォルダで、3つ目はそれらを含むフォルダ（<LAB>）で実行しています。
$ git status --short --ignored
!! .env
$ git worktree remove ../myapp-existing
$ ls -A <LAB>
experiment
hotfix
myapp
myapp-feature-a
myapp-feature-bmyapp-existing はフォルダごと無くなり、.env も一緒に消えています。消えると困るファイルがあるときは、消す前に git status --short --ignored で、無視されているファイル（!! と出るもの）が残っていないか確かめられます。
worktree を消してもブランチは残る（使用中のブランチは消せない）
worktree を消しても、ブランチは消えません。消えるのは worktree の作業フォルダで、そのブランチのコミットはリポジトリの履歴に残ります（VS Code の文書）。ブランチを消すのは、別の操作です。
次は、myapp-existing を git worktree remove で消したあとの、ブランチの一覧です（git 2.39.3 の出力）。existing-branch は残っていて、どの worktree でも開いていないので + は付いていません。
$ git branch --list
existing-branch
+ feature-a
+ feature-b
+ hotfix
* mainほかの worktree で開いているブランチは、git branch -d で消せません（git 2.39.3 の出力）。
$ git branch -d feature-a
error: Cannot delete branch 'feature-a' checked out at '<LAB>/myapp-feature-a'この文面も版で違います。2.42 までは Cannot delete branch '<ブランチ>' checked out at '<パス>'、2.43.0 からは cannot delete branch '<ブランチ>' used by worktree at '<パス>' です。
feature-a の worktree を消したあとなら、ブランチを消せます（git 2.39.3 の出力）。この例の feature-a には、main に無いコミットがありません。
$ git branch -d feature-a
Deleted branch feature-a (was b2d6738).フォルダを直接消してしまったとき（prune）
worktree のフォルダを、git worktree remove を使わずに消すと、リポジトリの中に記録（.git/worktrees の中）が残ります。次は、rm -rf で hotfix のフォルダを消したあとの、一覧の出力です（git 2.39.3 の出力）。hotfix に prunable と付いています。-v を付けると、理由（prunable: gitdir file points to non-existent location）が次の行に出ます。
$ rm -rf <LAB>/hotfix
$ git worktree list
<LAB>/myapp b2d6738 [main]
<LAB>/experiment b2d6738 (detached HEAD)
<LAB>/hotfix b2d6738 [hotfix] prunable
<LAB>/myapp-feature-a b2d6738 [feature-a]注意: rm -rf は、フォルダを丸ごと消すコマンドです。消す場所を間違えないよう、パスをよく確かめてください。この例は、直接消したあとの状態を見るためのもので、ふだんは git worktree remove を使います。
この記録は、いずれ自動で消えます。git gc が git worktree prune --expire 3.months.ago を呼ぶためで、この猶予は設定 gc.worktreePruneExpire で変えられます（git の設定の文書）。すぐに消したいときは、git worktree prune を使います。
記録が残っている間は、そのブランチはまだ「開いている」扱いで、別の worktree に add できません。同じ場所に add し直すのも断られます（git 2.39.3 の出力）。
$ git worktree add ../hotfix-again hotfix
Preparing worktree (checking out 'hotfix')
fatal: 'hotfix' is already checked out at '<LAB>/hotfix'
$ git worktree add ../hotfix
Preparing worktree (checking out 'hotfix')
fatal: '../hotfix' is a missing but already registered worktree;
use 'add -f' to override, or 'prune' or 'remove' to cleargit worktree prune は、フォルダが無くなった worktree の記録だけを消します。-n（--dry-run）を付けると、消さずに何を消すかだけを出します。-v を付けると、消したものを全部出します。prune のあとは、同じブランチを別の worktree に add できます（git 2.39.3 の出力）。
$ git worktree prune -n -v
Removing worktrees/hotfix: gitdir file points to non-existent location
$ git worktree prune -v
Removing worktrees/hotfix: gitdir file points to non-existent location
$ git worktree add ../hotfix-again hotfix
Preparing worktree (checking out 'hotfix')
HEAD is now at b2d6738 first commitgit の文書は、prune を、手で消したあとに使うものとして説明し、次からは git worktree remove を使うよう書いています。lock してある worktree は、フォルダが無くても prune されません。
サブモジュールとの組み合わせは不完全
サブモジュールは、リポジトリの中で別のリポジトリを使う仕組みです。git の文書の BUGS の節には、複数の checkout は全般にまだ experimental（試験的）で、サブモジュールの対応は不完全だと書かれています。サブモジュールを含む側のリポジトリ（スーパープロジェクト）を複数 checkout するのは、勧められていません（2026年10月時点の文書）。サブモジュールを含む worktree は、git worktree move では移せず、git worktree remove には --force が要ります。
AI コーディングツールでは worktree をどう使う？（2026年10月時点）
AI コーディングツールの公式の文書にも、worktree の説明があります。どれも、AI エージェントやチャットの作業を、メインの作業フォルダやほかの作業から分けて、並行して動かすために worktree を使う、という説明です。ここでは、公式の文書があるツールを、同じ項目で並べます。表の OpenAI Codex の行は、ChatGPT のデスクトップアプリでの使い方です。Windsurf は 2026年6月2日に Devin Desktop に名前が変わりました。
始め方と置き場所です。
| ツール | 始め方 | 置き場所 |
|---|---|---|
| Claude Code | claude --worktree <名前>（-w） | リポジトリ直下の .claude/worktrees/<名前>/ |
| OpenAI Codex | 新しいチャットの入力欄の下で Worktree を選ぶ | $CODEX_HOME/worktrees |
| Cursor | Agents Window（IDE では /worktree） | — |
| VS Code | Agents window で New Worktree を選ぶ（ソース管理では Create Worktree） | — |
| Gemini CLI（試験的） | gemini --worktree <名前>（先に設定で有効にする） | .gemini/worktrees/ の中 |
| Devin Desktop（旧 Windsurf） | Cascade の入力欄の右下で Worktree モードにする | ~/.windsurf/worktrees/<repo_name> |
.gitignore 対象のファイル（.env など）の扱いと、片付けです。
| ツール | .env などの扱い | 片付け |
|---|---|---|
| Claude Code | .worktreeinclude に書くとコピーされる | 変更が無ければ worktree とブランチを自動で消す（名前なしのセッション）。変更があれば聞く |
| OpenAI Codex | .worktreeinclude に書くとコピーされる | 既定で最近の 15 個を残す |
| Cursor | .cursor/worktrees.json に準備を書く | /delete-worktree。古いものは自動で片付ける（Cursor 3.5 以降。上限は既定で 1 台 25 個） |
| VS Code | 設定 git.worktreeIncludeFiles（Experimental） | メインのリポジトリを開いて Git: Delete Worktree... |
| Gemini CLI | worktree ごとに開発環境を準備する | 自動では消さない |
| Devin Desktop | post_setup_worktree フックでコピーする | 1 ワークスペースで最大 20 個。古いものから自動で片付ける |
表の「—」は、この記事では確かめていない項目です。ツールの機能は変わっていくので、使う前に各ツールの最新の文書を確かめてください。
- 新しい worktree の起点: 道具ごとに説明が違います。git の
add <パス>は HEAD から作ります。Claude Code の--worktreeは、既定ではリモートの既定ブランチ（ふつうは main）から作り、設定worktree.baseRefを"head"にすると今の HEAD から作ります。Codex は選んだブランチから detached HEAD で作業し、VS Code の Agents window は選んだ base branch から作ります。 - .env など: どのツールの文書も、新しい worktree に
.envなどが入らない前提で書かれています。.worktreeinclude（Claude Code・Codex）とgit.worktreeIncludeFiles（VS Code）は、.gitignore対象で、かつ書いた形に合うものだけをコピーします。Cursor の文書の例は、cp $ROOT_WORKTREE_PATH/.env .envで.envをコピーしています。 - 置き場所の勧め: Claude Code の文書は、
.claude/worktrees/を.gitignoreに足して、worktree の中身が追跡していないファイルとして出ないようにするよう勧めています。IntelliJ IDEA の文書は、プロジェクトのフォルダの中に worktree を作るのを勧めていません。git の文書の例は、../hotfixのような隣のフォルダです。 - 自動の片付け: Cursor の文書（Cursor 3.5 以降の説明）は、片付けのたびに Cursor の worktree の置き場（worktree root）を見直すので、そこにある、Cursor の管理の外で作った worktree（
/worktreeのスキルやgit worktree addで作ったもの）も、削除の対象になりうると書いています。 - 安全面: VS Code の文書は、worktree は変更を分けるだけで、セキュリティの境界ではない（エージェントが使えるコマンドやネットワークを制限するものではない）と書いています。
IntelliJ IDEA（JetBrains の IDE）にも worktree の機能があります。文書は、用途の1つとして、AI エージェントを別々の worktree で動かして、保存していない手元の変更を上書きさせないことを挙げています。対応は、1つのリポジトリだけを含むプロジェクトで、メインメニューの Git | New Worktree で作ります。
よくある質問
worktree を削除するには？ブランチも消える？
git worktree remove <worktree> で消します。消せるのは、追跡していないファイルも、追跡中のファイルの変更も無い worktree だけです。変更が残っているものは --force が必要で、lock されているものは --force を2回指定します。
ブランチは消えません。worktree を消しても、ブランチとそのコミットはリポジトリに残ります。ブランチを消すのは別の操作で、ほかの worktree で開いているブランチは git branch -d で消せません。.gitignore 対象のファイル（.env など）はフォルダごと消えるので、消す前に確かめてください。詳しくは、上の「worktree を消す（remove）」と「注意点」で説明しています。
フォルダを直接消してしまったら？（prune とは）
git worktree prune で、フォルダが無くなった worktree の記録（.git/worktrees の中）を消せます。記録が残っている間は、そのブランチは使用中の扱いで、別の worktree に add できません。prune すると、また使えるようになります。何が消えるかを先に見るには -n（--dry-run）、消したものを全部出すには -v を付けます。記録は、いずれ git gc からも自動で消えます。次からは git worktree remove を使うよう、git の文書は書いています。
worktree の切り替え方は？（worktree の中でブランチは替えられる？）
worktree はフォルダごとに分かれているので、別の worktree で作業するには、そのフォルダに移ります。git の文書の例では、pushd と popd で移っています。VS Code なら、worktree ごとに別の窓で開くか、File > Open Recent で切り替えます。
worktree の中で git switch して、ブランチを替えることもできます。ただし、ほかの worktree で開いているブランチへは切り替えられず、エラーになります（「注意点」の出力を参照）。
新しい worktree に .env や node_modules が無いのはなぜ？
git worktree add は、新しいフォルダにコミットの中身を取り出す（checkout する）だけで、今のフォルダをそのまま写すわけではないからです。.gitignore で外した .env や node_modules などは、新しい worktree に入りません。AI コーディングツールの文書には、コピーや準備の仕組みが用意されています（上の表）。
worktree はまとめて削除できる？
git worktree remove が指定できる worktree は1つだけです（書式は git worktree remove [-f] <worktree>）。2つ渡すと、git 2.39.3 では使い方の表示で止まります。まとめて消す公式のコマンドは、git の文書には書かれていません（2026年10月時点）。prune は、フォルダが無くなった worktree の記録だけを消すもので、残っている worktree を消すものではありません。AI コーディングツールには、古い worktree を自動で片付けるものがあります（上の表の「片付け」）。
まとめ
- git worktree は、1つのリポジトリに作業フォルダを複数つなげて、複数のブランチを同時に開いておく仕組みです。履歴やブランチは共有し、作業中のファイル・ステージ・コミットしていない変更は worktree ごとに別々です。
- ブランチの切り替えは1つのフォルダの中身を入れ替え、stash はコミットしていない変更を脇に置き、clone はリポジトリを複製します。worktree は、別々のフォルダで複数のブランチを同時に開いたままにします。
- 基本は、
add（足す）・list（一覧）・remove（消す）です。場所を移すのはmove、外付けドライブなどに置いた worktree を守るのはlockです。 - 同じブランチは2か所で開けません。エラーの文面は、2.43.0 から
is already used by worktree atに変わりました。 .gitignore対象のファイル（.envなど）は新しい worktree に入らず、removeすると一緒に消えます。worktree を消しても、ブランチは残ります。- フォルダを直接消してしまったときは、
git worktree pruneで記録を消します。次からはgit worktree removeを使います。 - サブモジュールとの組み合わせは不完全です（git の文書の BUGS の節。2026年10月時点）。
- Claude Code・Codex・Cursor・VS Code・Gemini CLI・Devin Desktop の文書も、worktree で作業を分ける使い方を説明しています（2026年10月時点）。
参考資料
- git-worktree（git の公式の文書）
- git-stash・git-switch・git-clone・git-branch（git の公式の文書）
- git-config の gc.worktreePruneExpire
- git のリリースノート: 2.29.0・2.36.0・2.42.0・2.43.0・2.48.0
- エラーの文面の根拠にした git のソース: branch.c（v2.42.0）・branch.c（v2.43.0）・builtin/branch.c（v2.39.0）・builtin/branch.c（v2.43.0）
- git の翻訳ファイルの一覧（v2.56.0）
- VS Code の文書（ブランチと worktree）
- VS Code の文書（Agents window）
- IntelliJ IDEA の文書: Git ワークツリーを使用する（英語版）
- Claude Code の文書: worktree を使用して並列セッションを実行する（英語版）
- OpenAI Codex の文書（Worktrees）
- Cursor の文書（Worktrees）
- Gemini CLI の文書（Git worktrees）
- Devin Desktop の文書（Worktrees）・Windsurf is now Devin Desktop
※この記事は、公式の資料をもとに AI（Claude）で下書きし、2026年10月3日時点の公式の資料と照らして確かめてから公開しています。誤りに気づいたらお問い合わせからお知らせください。
