Git worktreeの使い方｜Sourcetree・Fork・VS Code対応とwtp（worktree plus）・move・並行開発の手順

Git worktreeは、1つのリポジトリで複数のブランチを別々のフォルダに同時に開いておけるGitの標準機能です。コマンドだけでも使えますが、実務でつまずくのは「普段のGUIクライアントでworktreeを作れるか」「フォルダの場所を変えたい」「毎回 .env をコピーするのが面倒」「作業中に割り込んだhotfixやレビューをどう並行させるか」といった周辺の操作です。この記事では、Sourcetree・Fork・VS Code・IntelliJ IDEA・Eclipse・Xcodeのworktree対応を2026年10月時点の対応版つきで整理し、CLIの補助ツールwtp（Worktree Plus）の使い方、git worktree move と repair、--detach と lock の使いどころ、hotfixとプルリクエストのレビューを別フォルダで進める手順を、Git 2.50.1・Git 2.56.0とwtp v2.10.3の実行結果で解説します。Git 2.56.0（2026-09-28）で加わった includeIf "worktree:" と、同名ブランチが複数のリモートにあるときのエラーも扱います。worktreeの仕組みや remove・prune による削除の詳細はGit Worktreeとは｜使い方・削除とsubmodule併用の注意点で扱っています。

まとめ：GUI・wtp・move・並行開発で押さえる要点

• worktreeの作成・削除をGUIで行えるのは、Fork（Mac 2.41／Windows 1.96以降）、VS Code 1.103以降、IntelliJ IDEA 2026.1以降、Tower、GitKraken Desktop、GitHub Desktop 3.6以降です。
• Sourcetreeは、Mac 4.2.19・Windows 3.4.32までのリリースノートにworktree作成機能の記載がありません。ターミナルで作ったworktreeのフォルダをリポジトリとして追加して使います。EclipseのEGitは基盤のJGitがworktree未対応で、Xcodeは26〜27.1のリリースノートにworktreeの記述がありません。
• wtp（worktree plus）は wtp add -b ブランチ名 だけで作成先のパスを決め、.wtp.yml のフックで .env のコピーや npm install まで自動化します。prune・lock・move のコマンドはありません。
• フォルダの移動は git worktree move で行います。エクスプローラーなどで動かした場合は、prune より先に移動後のフォルダで git worktree repair を実行してつなぎ直します。
• hotfixやレビューを別のworktreeで進めると、元の作業をstashに退避せず、起動中の開発環境も維持できます。ただし、新しいworktreeでは依存物のインストールやビルドが必要になる場合があります。
• Git 2.56.0以降は includeIf "worktree:<パス>" で、worktreeを置いた場所ごとに user.email などを切り替えられます。パスはシンボリックリンクを解決した実体パスで書きます。
• 作成と削除の入口はGUIかwtpかgitのどれか1つに決めておくと、管理外のworktreeや消し残しを防げます。

git worktreeのサブコマンド一覧と各コマンドが追加されたGitの版

GUIやwtpは、内部で次の git worktree サブコマンドを呼んでいます（仕様はgit-worktree公式マニュアル）。move と remove はGit 2.17からなので、それより古いGitを同梱したGUIやサーバーでは使えません。

手元で使っているGitの版を確認するコマンドは git --version です。2026年10月時点の現行版はGit 2.56.0（2.56.0のリリースノート）で、worktreeに関わる変更は後半の2つの章で実行結果とあわせて扱います。更新方法はGitの最新バージョンと確認・アップデート方法にまとめています。ほかのGitコマンドとの関係を早見表で見たい場合はGitコマンド一覧｜用途別早見表とよく使う基本コマンドが入口になります。

git worktreeでの並行開発：hotfix割り込みとプルリクエストのレビュー

worktreeが効くのは、作業中のブランチを中断したくない場面です。従来は git stash で変更を退避してブランチを切り替え、戻ってきたら git stash pop で戻す手順が一般的でした。この方法では、ブランチ間で異なるファイルが書き換わるため、変更内容や開発環境によっては、開発サーバーの再起動や再ビルドが必要になります。退避したまま忘れたstashの整理はgit stashの削除：drop・clearの使い分けと消したstashの復元手順で扱っています。worktreeならフォルダごと分かれるので、元の作業は止まりません。以下は、originを登録済みのリポジトリで実行する手順例です。パス・ブランチ名・PR番号は環境に合わせて変更してください。レビュー例は、Node.jsとnpmを導入済みで、整合したpackage-lock.jsonとtestスクリプトがあるプロジェクトを前提とします。

作業中のfeatureを止めずにhotfixを別フォルダで修正してpushする手順

本番障害の修正依頼が入ったときの流れです。いまのフォルダ app は feature/search の作業途中で、未コミットの変更が残っている前提とします。

# 1. リモートの最新を取得（fetchは全worktreeで共有される）
$ git fetch origin

# 2. origin/main を起点にhotfixブランチとworktreeを同時に作る
$ git worktree add -b hotfix/login-500 ../app-hotfix origin/main

# 3. hotfix用フォルダで修正・コミット・push
$ cd ../app-hotfix
$ git commit -am "ログイン時の500エラーを修正"
$ git push -u origin hotfix/login-500

# 4. プルリクエストがマージされたら片付ける
$ cd ../app
$ git worktree remove ../app-hotfix
$ git branch -d hotfix/login-500

手順2の -b は、新しいブランチの作成とworktreeの作成を1回で済ませる指定です。起点にリモート追跡ブランチの origin/main を渡すと、既定の設定では新しいブランチの上流が origin/main になります。そのため手順3では -u を付けてpushし、上流を同名のリモートブランチへ付け替えます。手順4の git branch -d は、設定された上流へのマージ状態を判定します。この例ではpush先のリモート追跡ブランチが残っていれば、mainへのマージ前でも削除できます。上流が削除・pruneされた場合などには、squashマージ後でも「未マージ」と判定されることがあります。その場合はマージ済みであることをGitHub上で確かめてから -D で消してください。hotfixブランチをどこから切り、どこへ戻すかというブランチ運用そのものはdevelopブランチとは？featureブランチの意味とrelease・hotfixとの違いで整理しています。

プルリクエストをレビュー用worktreeに取り出してテストを回す手順

差分を画面で読むだけでは判断しにくいプルリクエストは、手元で動かして確かめます。GitHubはプルリクエストごとに pull/番号/head という参照を用意しており、GitHub公式ドキュメントのローカルチェックアウト手順どおりにfetchすれば、フォーク元のブランチも取得できます。これをworktreeとして展開すれば、自分の作業フォルダを汚さずにレビューできます。

# プルリクエスト#123をローカルブランチ pr-123 として取得
$ git fetch origin pull/123/head:pr-123

# レビュー用のworktreeを作り、依存を入れてテストを実行
$ git worktree add ../app-pr-123 pr-123
$ cd ../app-pr-123
$ npm ci
$ npm test

# レビューが終わったら worktree とローカルブランチを消す
$ cd ../app
$ git worktree remove ../app-pr-123
$ git branch -D pr-123

レビュー用ブランチはローカルではどこにもマージされないので、最後は -d ではなく -D で消します。プルリクエストが更新された後に同じ git fetch origin pull/123/head:pr-123 を実行し直すと、pr-123 はレビュー用worktreeでチェックアウト中のため、Gitがそのブランチへの書き込みを拒否します。更新を取り込むときはレビュー用worktreeの中で git pull origin pull/123/head を実行し、作者がforce pushしている場合はworktreeを消して取り直します。レビューで何を確かめるかという観点の整理はコードレビューとは？目的・観点・進め方と実装現場の運用設計を参照してください。

GUIクライアント・IDE別のworktree作成・削除への対応版（2026年10月時点）

各ツールの公式リリースノートとドキュメントで、worktreeの作成・削除に対応した版を確認しました。「既存のworktreeを表示できる」だけの版と「GUIから作れる」版は別なので、作成・削除に対応した版を載せています。

出典：Fork for Mac リリースノート、Fork for Windows リリースノート、VS Code 1.103 リリースノート、IntelliJ IDEA ヘルプ、Tower リリースノート、GitKraken Desktop 10.x リリースノート、GitHub Desktop 3.6.0 リリース、JGit README、Xcode 27 リリースノート。

GitHub Desktopは3.6.7（2026-10-14）で、ツールバーのworktree欄を常に表示する「Always show worktree list」設定を加えました（GitHub Desktop 3.6.7 リリース）。3.6のworktree画面とCopilot連携の変更点はGitHub Desktop 3.6の新機能｜worktree対応とCopilot連携強化で解説しています。

Forkでworktreeを作成する手順とブランチ削除に連動して消すオプション

Forkは既存worktreeの表示（Mac 2.31・2023年7月）から始まり、作成・削除（Mac 2.41）、「Create Worktree」ダイアログとQuick Launchからの呼び出し（Mac 2.63・2026年2月／Windows 2.17・2026年3月）、リモートブランチを直接worktreeとしてチェックアウトする機能（Mac 2.68・2026年6月／Windows 2.21・2026年7月）と段階的に機能が増えています。2026年10月時点の最新版はMac 2.70（2026-09-04）とWindows 2.23（2026-09-25）です。現行版での手順は次のとおりです。

1. サイドバーのWorktreesを右クリックするか、Quick Launchで「Create Worktree」を実行する
2. チェックアウトするブランチと作成先フォルダを指定する
3. 作成されたworktreeはサイドバーのWorktreesに並び、ダブルクリックで別タブとして開く

ほかのworktreeでチェックアウト中のブランチにはworktreeのアイコンが付くので（Mac 2.59／Windows 2.17以降）、同じブランチを二重に開こうとする前に気づけます。Mac 2.63からはブランチ削除時に対応するworktreeも一緒に消すオプションが加わりました。Windows 2.23では、非表示にしたタグやスタッシュなどの表示設定がworktreeごとに保存され、新しいworktreeは作成元の表示設定を引き継ぐ一方、リポジトリ設定はworktree間で共有される仕様に変わっています。

Sourcetreeでworktreeを扱う方法：ターミナルで作りブックマークで開く運用

Sourcetreeには、worktreeを作成・一覧・削除するメニューが公式に案内されていません。2026年10月時点の最新版であるMac 4.2.19（2026-07-30）とWindows 3.4.32（2026-08-28）までのSourcetree for Mac リリースノートにも該当機能の記載はありません。2015年10月に起票されたMac版の要望チケット（SRCTREE-3204「Add git 2.5 worktree command support」）は、Resolutionが「Unresolved」・修正版なしのままクローズされ、Windows版の要望（SRCTREEWIN-8594）は「Gathering Interest」のままです。

運用は「作るのはターミナル、開くのはSourcetree」に分けます。git worktree add ../app-hotfix hotfix/login のように作ったフォルダを、Sourcetreeの新規タブから既存のローカルリポジトリとして追加すれば、そのフォルダのブランチでコミットや差分確認ができます。削除はSourcetreeのブックマークを外したうえで、ターミナルから git worktree remove を実行してください。ブックマークを外すだけではworktreeの管理情報は残ります。Sourcetree自体の導入と、ターミナル操作をボタン化するカスタムアクションの登録はSourcetreeの使い方｜インストールから認証・カスタムアクションまでで扱っています。

VS Codeのソース管理ビューでworktreeを作成・削除し.envや依存フォルダを引き継ぐ設定

VS Codeは1.103でworktreeにネイティブ対応しました。拡張機能は要りません。2026年10月時点の安定版は1.142（2026-10-14）で、版の確認と更新の手順はVS Codeの最新バージョンと確認・アップデート手順にまとめています。

• 作成：ソース管理のリポジトリビューで対象リポジトリの「…」から「Worktrees」→「Create Worktree」を選び、ブランチと作成先を指定する
• 開く：リポジトリビューでworktreeを右クリックし「Open Worktree in New Window」か「Open Worktree in Current Window」を選ぶ
• 削除：メインのリポジトリを開いた状態でコマンドパレットから「Git: Delete Worktree…」を実行する（ブランチは消えない）
• 既存worktreeの自動検出：git.detectWorktrees を有効にする（既定は無効）。検出数の上限は git.detectWorktreesLimit（既定50）

.gitignore 対象の .env や node_modules は新しいworktreeにコピーされません。VS Codeには、作成時に引き継ぐための実験的設定が2つあります（VS Code公式のBranches and Worktrees）。

• git.worktreeIncludeFiles（1.109で導入）：".env" のようにパターンを並べると、一致し、かつ .gitignore に載っているファイルだけが作成時にコピーされる
• git.worktreeSymlinkFolders（1.140・2026-09-30で導入）：node_modules のように追跡ファイルを含まない無視フォルダを、コピーせずシンボリックリンクで共有する

シンボリックリンクで共有したフォルダへの変更は、つながっている全worktreeに及びます。ブランチごとに依存関係が変わるリポジトリでは git.worktreeSymlinkFolders を使わず、コピーか入れ直しにしてください。削除時は、公式ドキュメントが注意書きで示すとおり、Gitが変更なしと判定していても無視ファイルごとフォルダが消えます。Copilotなどのエージェントセッションが作ったworktreeは、1.141で加わった「Chat: Open Worktree Cleanup」で使用容量を見ながらまとめて片付けられます。

IntelliJ IDEAのworktree作成・管理と単一リポジトリの制限

IntelliJ IDEAは2026.1でworktreeの作成・切り替え・管理に正式対応しました。ただし、対応対象は単一リポジトリのプロジェクトです。公式ヘルプは、プロジェクトのフォルダの中にworktreeを作るとマルチルートのプロジェクトと誤認されて連携が壊れるとして、入れ子の作成を避けるよう求めています。GitツールウィンドウのWorktreesタブにある「New Worktree」か、メインメニューの「Git | New Worktree」から作成します。2026.2のヘルプでは、フォルダを手で消したworktreeがWorktreesタブに「Prunable」と表示され、Prune操作で管理情報を消せると案内されています。フォルダを動かしただけの場合にPruneを押すと管理情報が消えるので、後述のrepairを先に試してください。

Eclipse（EGit）のlinked worktree対応状況

Eclipseは状況が異なります。EGitの基盤であるJGitの公式READMEは、未実装機能の一覧に「support for multiple working trees (git-worktree)」を挙げています（2026年10月時点）。欠けているのは管理画面だけではなく、linked worktreeという仕組みそのものです。Eclipseでworktreeを使う場合は、作成・削除・移動に加えて、linked worktree上のコミットや差分確認もEGitに頼らず、ターミナルの git worktree と git で行う前提で計画してください。

Xcodeでのworktree作成・管理の対応状況

Xcodeは、Apple公式のXcode 26.0.1〜26.6と27・27.1のリリースノートをMarkdown版で取得して全文検索すると、「worktree」は0件でした（2026年10月19日に確認）。Xcode側の作成・管理画面は案内されていないため、作成・削除・移動はターミナルかForkなどのGitクライアントで行います。

wtp（worktree plus）による作成先指定と初期セットアップの自動化

wtpは、satococoa氏がGitHubで公開しているGo製のCLIツールで、正式名はWorktree Plusです（MITライセンス）。2026年10月19日時点の最新版はv2.10.3（2026年3月8日公開）です。git worktree をラップし、作成先パスの自動決定、作成後のセットアップ、worktree間の移動を短いコマンドにまとめます。READMEの動作要件はGit 2.17以降で、配布バイナリはLinux（x86_64／ARM64）とApple Silicon Mac向けです。Windowsは要件に記載がありません。

wtpのインストールと.wtp.ymlの初期設定で決まる作成先ディレクトリ

# Homebrew（macOS/Linux）
brew install satococoa/tap/wtp

# Go環境がある場合（Intel Macもこちらで入る）
go install github.com/satococoa/wtp/v2/cmd/wtp@latest

# リポジトリ直下で設定ファイルを作る
wtp init

wtp init で作られる .wtp.yml の既定は base_dir: ../worktrees です。つまりリポジトリと同じ階層の worktrees フォルダの下に、ブランチ名どおりのサブフォルダが作られます。Homebrewで入れた場合は、シェルで wtp と入力して最初にTabキーを押したときに、タブ補完と wtp cd 用のシェル連携が読み込まれ、go install の場合は eval "$(wtp shell-init zsh)" をシェルの設定ファイルに1行足します。

なお、wtp init が生成するひな形には、作成後に wtp list を実行するフックが1つ有効な状態で入っています。wtp にPATHが通っていない環境では、作成のたびに「Hook execution failed」という警告が出ます（worktree自体は作成されます）。

wtpのadd・list・cd・execの実行例とブランチ名だけで作成できる仕組み

$ wtp add -b feature/x      # 出力の絵文字は省略
Worktree created successfully!
Location: /private/tmp/wtlab2/worktrees/feature/x
Branch: feature/x

$ wtp list                  # ls でも同じ
PATH      BRANCH    STATUS  HEAD
----      ------    ------  ----
@*        main      managed f073c51d
feature/x feature/x managed f073c51d

$ wtp cd feature/x        # 絶対パスを出力（シェル連携時は移動する）
$ wtp exec feature/x -- git status --short
$ wtp cd @                # メインのworktreeへ戻る

git worktree add ならパスとブランチを両方書くところを、ブランチ名だけで済ませられるのがwtpの中心機能です。ローカルにないブランチ名を渡すと、リモートに同名ブランチが1つだけあれば追跡ブランチとして作ります。複数のリモートに同名ブランチがあるときはエラーで止まります。

スクリプトやエディタの起動と組み合わせるときは、wtp add の2つのオプションが便利です。--quiet（-q）は作成したworktreeの絶対パスだけを標準出力に出し、--exec はフックの実行後に新しいworktreeの中でコマンドを1つ実行します。

$ wtp add -b feature/q --quiet
/tmp/wtlab256/worktrees/feature/q

$ code "$(wtp add -b feature/r --quiet)"        # 作ってすぐVS Codeで開く
$ wtp add -b feature/e --exec "npm test"       # 作成直後にテストを流す

post_createで.envコピー・依存物共有・npm installの自動化

素の git worktree add では .gitignore 対象のファイルは新しいworktreeに入りません。以下のcopyフックを設定した同じリポジトリで試すと、.env はwtpで作ったworktreeには入り、gitで作ったworktreeには .git・.gitignore・追跡ファイルしかありませんでした。wtpでは .wtp.yml の post_create に3種類のフックを書けます。

version: "1.0"
defaults:
  base_dir: ../worktrees
hooks:
  post_create:
    - type: copy          # メインworktreeからコピー（無視ファイルも可）
      from: .env
    - type: symlink       # 大きいフォルダは共有
      from: .bin
      to: .bin
    - type: command       # 新しいworktreeの中で実行
      command: npm install

copy の from は、どのworktreeから wtp add を実行してもメインworktree基準で解決されます。node_modules を symlink で共有するとインストール時間は省けますが、ブランチごとに依存関係が違うと壊れるので、依存が変わりうるブランチでは command で入れ直すほうが安全です。VS Codeの git.worktreeSymlinkFolders も同じ考え方で、注意点も同じです。

wtpの未対応操作とremove --with-branchの途中失敗条件

v2.10.3の wtp --help に並ぶコマンドは add・list（別名 ls）・remove（別名 rm）・init・cd・exec・hook・shell-init の8つに加え、ヘルプ表示用の help があります。prune・lock・move・switch はありません。prune・lock・moveは git worktree を直接使い、作業場所の切り替えには wtp cd またはシェルの cd を使います。

実行して分かった注意点は2つです。

• 管理外のworktreeは操作できない：base_dir の外にあるworktree（GUIやgitで別の場所に作ったもの）は、wtp list で unmanaged と表示されるだけで、wtp remove や wtp cd に渡すと「worktree ‘../det’ not found」になります。
• ブランチ削除は途中で失敗しうる：wtp remove --with-branch は、ブランチが未マージだとworktreeを消した後にブランチ削除だけ失敗します（「failed to remove branch ‘feature/x’ … Branch is not fully merged」）。worktreeは戻らず、ブランチだけが残ります。未マージのまま捨てると決めているときだけ --force-branch を足してください。

未コミットのファイルがあるworktreeは wtp remove が拒否し、コミットか退避、または --force を促します。この点は git worktree remove と同じです。

git worktree moveでの移動と手動移動後のrepairによる修復手順

worktreeのフォルダを別の場所へ移すときは git worktree move を使います。管理情報のパスも一緒に書き換わります。

$ git worktree add -q ../plain -b feature/p
$ git worktree move ../plain ../moved
$ git worktree list
/private/tmp/wtlab2/app    f073c51 [main]
/private/tmp/wtlab2/moved  f073c51 [feature/p]
$ ls .git/worktrees
plain

.git/worktrees 配下の管理ディレクトリ名は、移動後も作成時の plain のままです。スクリプトで管理ディレクトリ名とフォルダ名が一致すると決め打ちしていると、移動後にずれます。

move で動かせないものは3つあります。メインworktree、submoduleを含むworktree、lock中のworktree（-f を2回付ければ移動できる）です。

エクスプローラーや mv で動かしてしまった場合、メイン側の記録は古いパスを指したままになります。

$ mv ../moved ../moved2
$ git worktree list
/private/tmp/wtlab2/moved  f073c51 [feature/p] prunable
$ git worktree repair ../moved2
repair: gitdir incorrect: /private/tmp/wtlab2/app/.git/worktrees/plain/gitdir
$ git worktree list
/private/tmp/wtlab2/moved2  f073c51 [feature/p]

ここで prunable と出た状態のまま git worktree prune を先に実行すると、管理情報が削除されてしまいます。手動で移動した後は、prune より先に repair を実行してください。メインworktreeを手動で動かした場合は、逆にメイン側で git worktree repair を実行するとリンクが張り直されます。GUIでは、Tower for Windows 14.1（2026-10-06）がフォルダを動かしたworktreeに新しい場所を指定してつなぎ直す「Repair Worktree…」を追加しています。

--detachとlockの使いどころ：検証用worktreeの作成と外付けドライブの保護

--detachでブランチを作らずに過去のコミットを検証用に展開する方法

git worktree add --detach ../det（短縮形 -d）は、ブランチを作らずに現在のコミットをdetached HEADで展開します。リリースタグや過去のコミットを検証するときは、git worktree add --detach ../det <タグ名またはコミットID> のように対象を末尾に指定します。以下の例は対象を省略しているため、現在のHEADを展開します。

$ git worktree add --detach ../det
Preparing worktree (detached HEAD f073c51)
$ git worktree list
/private/tmp/wtlab2/det     f073c51 (detached HEAD)

ブランチを使わないので、次に説明する同一ブランチの制約にもかかりません。ただし、ここでコミットしてからworktreeを削除すると、そのコミットはどこからもたどれなくなります。残す作業が出てきたら、削除前に git switch -c でブランチを付けます。削除時の挙動の詳細はgit worktreeの削除（remove／prune）の解説を参照してください。

外付けSSD・ネットワーク共有のworktreeをprune・削除から守るlock設定

外付けSSDやネットワーク共有上に作ったworktreeは、未接続の間に prune で「消えた」と判定され、管理情報を消されるおそれがあります。lock はこれを防ぎ、同時に移動と削除も止めます。

$ git worktree lock --reason "USB drive" ../moved2
$ git worktree remove ../moved2
fatal: cannot remove a locked working tree, lock reason: USB drive
use 'remove -f -f' to override or unlock first
$ git worktree unlock ../moved2

作成と同時にロックするなら git worktree add --lock --reason "..." <パス> と書けます。git worktree list ではロック中のworktreeに locked が付きます。

「is already used by worktree at」の3操作と目的別対処

Gitは、1つのローカルブランチを複数のworktreeで同時にチェックアウトさせません。そのため、次の3つの操作はどれも同じ種類のエラーで止まります。

$ git worktree add ../w2 feature/p
fatal: 'feature/p' is already used by worktree at '/private/tmp/wtlab2/moved2'
$ git switch feature/p
fatal: 'feature/p' is already used by worktree at '/private/tmp/wtlab2/moved2'
$ git branch -d feature/p
error: cannot delete branch 'feature/p' used by worktree at '/private/tmp/wtlab2/moved2'

対処は目的で選びます。そのブランチで作業したいなら、エラーに出たパスのworktreeへ移動して作業します。中身を見たいだけなら、--detach で同じコミットを別フォルダに展開する方法が選択肢です。ブランチを消したいなら、先にそのworktreeを remove します。git branch の一覧で先頭に + が付いているブランチが、ほかのworktreeでチェックアウト中のものです。

git worktree add -f を付けるとこの安全装置を外せますが、使うべきではありません。片方のworktreeでコミットするとブランチの先端が進み、もう片方のworktreeではファイルが古いまま残るため、次にコミットすると相手の変更を取り消す差分が混ざります。

同名ブランチが複数のリモートにあるときのworktree add：Git 2.56.0の「matched multiple remote tracking branches」

git worktree add ../wA feat のようにローカルにないブランチ名を渡すと、Gitはリモート追跡ブランチから同名のものを探して追跡ブランチを作ります。フォーク元の upstream と自分の origin の両方に feat があると、候補が2つになります。この状態をGit 2.50.1と2.56.0で同じ手順で再現すると、結果が変わりました。

# origin/feat と other/feat が両方ある状態
## Git 2.50.1
$ git worktree add ../wA feat
fatal: invalid reference: feat

## Git 2.56.0
$ git worktree add ../wA feat
hint: Branch name 'feat' appears in multiple remotes:
hint:   origin
hint:   other
（中略）
hint: consider setting checkout.defaultRemote=origin in your config.
fatal: 'feat' matched multiple (2) remote tracking branches

2.50.1の「invalid reference」はブランチが存在しないときと同じ文言で、原因に気づきにくいエラーでした。2.56.0は候補のリモート名と回避方法を表示します。影響が大きいのは、パスだけを渡してブランチ名を推測させる --guess-remote（設定 worktree.guessRemote）です。2.50.1は候補が2つあると、上流の設定がない新しい feat ブランチを現在のHEADから黙って作りました。2.56.0は同じ操作を「matched multiple (2) remote tracking branches」で止めます（git-worktreeマニュアルの --guess-remote の項にも、複数一致なら失敗すると追記されました）。

どちらの版でも、回避方法は次の2つです。以下は代替案なので、ローカルにfeatブランチがない状態で、どちらか一方だけを実行してください。

# 1. 起点のリモートを明示する（どの版でも動く）
$ git worktree add -b feat ../wC other/feat
branch 'feat' set up to track 'other/feat'.

# 2. 優先するリモートを設定しておく
$ git config checkout.defaultRemote origin
$ git worktree add ../wB feat
branch 'feat' set up to track 'origin/feat'.

フォークしたリポジトリで upstream と origin を両方登録しているなら、checkout.defaultRemote を設定しておくと git switch と git worktree add の両方で同じリモートが優先されます。

worktreeごとに設定を切り替えてスクリプトで判別する：includeIf “worktree:”と–git-common-dir

置き場所でuser.emailを切り替えるincludeIf “worktree:”（Git 2.56.0以降）の書き方

Git 2.56.0で、設定ファイルの条件付き読み込み includeIf に worktree: 条件が加わりました（Git 2.56.0のconfigドキュメント）。worktreeの作業ディレクトリ（git rev-parse --show-toplevel が返すパス）がパターンに一致したときだけ、指定した設定ファイルを読み込みます。仕事用のフォルダに置いたworktreeだけ会社のメールアドレスでコミットする、といった切り替えをグローバル設定に1回書くだけで済ませられます。

# ~/.config/git/config（グローバル設定）
[includeIf "worktree:/Users/me/work/"]
	path = ~/.config/git/work.inc

# ~/.config/git/work.inc
[user]
	email = [email protected]

macOSで /tmp の下にworktreeを置いて試すと、注意点が2つ見えました。

# worktree は /tmp/wtlab256/work/review（実体は /private/tmp/...）
## Git 2.56.0
[includeIf "worktree:/private/tmp/wtlab256/work/"]  → [email protected]（一致）
[includeIf "worktree:/tmp/wtlab256/work/"]          → [email protected]（不一致）

## Git 2.50.1
[includeIf "worktree:/private/tmp/wtlab256/work/"]  → [email protected]（エラーも出ない）

• パスは実体パスで書く：worktree: 条件はシンボリックリンクを解決した後のパスとだけ照合されます。macOSの /tmp は /private/tmp へのリンクなので、/tmp/... と書くと一致しません。ドキュメントにも、シンボリックリンク経由の表記では一致しない場合があり実体パスを使うよう書かれています。
• 古いGitは黙って無視する：Git 2.50.1は worktree: を知らない条件として読み飛ばし、警告も出しません。GUIが同梱する古いGitでコミットすると、メールアドレスが切り替わらないままコミットされます。

従来の extensions.worktreeConfig と git config --worktree による設定はworktreeを作るたびに個別の操作が要るので、置き場所で決まる設定は includeIf "worktree:"、特定のworktreeだけの例外は --worktree と使い分けます。

スクリプトでlinked worktreeかを判別する–git-dirと–git-common-dirの違い

フックやビルドスクリプトで「いまメインのworktreeにいるか」を判定したいときは、git rev-parse の2つのオプションを比べます。--git-dir はそのworktree専用の管理ディレクトリ、--git-common-dir は全worktreeで共有するリポジトリ本体の .git を返します。

# linked worktree の中（Git 2.56.0）
$ git rev-parse --show-toplevel
/private/tmp/wtlab256/work/review
$ git rev-parse --git-dir
/private/tmp/wtlab256/app/.git/worktrees/review
$ git rev-parse --git-common-dir
/private/tmp/wtlab256/app/.git

# メインのworktreeの中
$ git rev-parse --git-dir
.git
$ git rev-parse --git-common-dir
.git

2つが同じならメインのworktree、違えばlinked worktreeです。メインでは相対パスの .git が返るので、比較やログ出力には git rev-parse --path-format=absolute --git-common-dir のように絶対パスを指定します（--path-format はGit 2.31以降）。既定のフック置き場（hooks）とリモート設定はこの共有側（--git-common-dir）にあるため、何も設定しなければフックは全worktreeで共通に動きます。

GUIとCLIを混ぜたworktree運用で起きる4つの失敗パターンと防ぎ方

worktreeの入口が複数あるチームで起きやすい失敗を、原因と合わせて並べます。

• 作成先がばらばらになる：wtpは ../worktrees、VS CodeやForkは作成時に指定した場所へ作ります。wtpは自分の base_dir の外にあるworktreeを unmanaged として一覧に出すだけで、削除や移動の対象にできません。
• フォルダをゴミ箱に入れて終わりにする：Sourcetreeのブックマーク削除だけではフォルダもGitの管理情報も残ります。ファイルマネージャーでworktreeのフォルダを削除した場合は管理情報だけが残り、git worktree list に prunable が並びます。ブランチも「使用中」のまま削除できません。
• 無視ファイルを消してしまう：git worktree remove もVS Codeの「Delete Worktree」も、.env や手元のビルド成果物など .gitignore 対象のファイルでは止まりません。残したいファイルは削除前に外へ出してください。
• 古いGitを同梱したGUI：move・remove はGit 2.17、repair は2.29、includeIf "worktree:" は2.56.0からです。GUIが同梱するGitの版と、ターミナルで使うGitの版が違う環境では、同じ操作や設定の結果が変わることがあります。

作成先を統一し、削除前の無視ファイル確認と正規の削除操作をチームの手順にします。そのうえでチームとして決めるのは、作成と削除をどのツールから行うかという共通の入口です。CLI中心のチームならwtp、GUI中心ならForkかVS Codeに寄せ、Sourcetreeのように作成機能がないツールは「開くだけ」に使います。

worktreeをチームの開発フローに入れる判断：採用する条件と見送る場面

worktreeは個人の便利機能として始めやすい一方、チームの標準手順にするかどうかは条件で分かれます。次のどれかに当てはまるなら、標準手順に入れる価値があります。

• 割り込みが多い：hotfixや他メンバーのレビュー依頼が週に何度も入り、そのたびにstashとブランチ切り替えで作業が途切れている
• ビルドや起動が重い：ブランチを切り替えるたびに依存の入れ直しや再ビルドに数分かかり、作業フォルダを分けたほうが待ち時間が減る
• AIエージェントを並列で動かす：Claude CodeやCopilot CLIなどに複数の作業を同時に任せ、ファイルの変更が混ざるのを防ぎたい

反対に、次の場面では見送るか範囲を絞ります。submoduleを多用するリポジトリは、新しいworktreeでsubmoduleの初期化が別途必要になり、移動もできません。Eclipse中心のチームはEGitがlinked worktreeを扱えないため、ターミナル操作を全員に求めることになります。ブランチの切り替えが1日1回程度で、ビルドも数秒で終わるなら、git switch だけで十分です。

導入すると決めたら、作成先のディレクトリ規則、作成と削除の入口（wtp・GUI・gitのどれか）、.env の扱い、マージ後の片付けの4点を手順書に書き、CIのジョブやブランチ保護ルールと矛盾しないかを確かめます。ブランチ運用からCI/CDのパイプラインまでをまとめて見直したい場合は、一創のDevOps・CI/CD導入支援で、現状のリポジトリ構成とリリース手順に合わせた設計からお手伝いしています。

よくある質問

git worktreeに既定の作成先（default path）はありますか？

Git本体には既定の作成先を決める設定はなく、git worktree add のたびにパスを指定します。パスだけを渡した git worktree add ../hotfix は、パスの最後の要素と同じ名前の hotfix ブランチがなければ新しく作り、既にあればそのブランチを使います。ただし、そのブランチが別のworktreeで使用中の場合、Gitは作成を拒否します。作成先を固定したい場合は、wtpの base_dir を使います。

.gitignoreはworktreeごとに別々ですか？

.gitignore は追跡ファイルなので、各worktreeでチェックアウトしたブランチの内容が使われます。一方、.git/info/exclude はリポジトリ単位で、同じリポジトリにつながる全worktreeで共有されます。Git 2.55のリリースノートで、この共有がドキュメントに明記されました。

worktreeごとにgit pullやfetchが必要ですか？

同じリポジトリにつながるworktreeであれば、git fetch の実行は1回で十分です。リモート追跡ブランチはリポジトリ全体で共有されるため、どのworktreeで取得しても全worktreeから見えます。ただし、取得した変更を自分のブランチへ取り込む merge や pull は、そのブランチをチェックアウトしているworktreeごとに実行します。

worktreeを増やすとディスク容量はどれくらい増えますか？

コミットやオブジェクトは全worktreeで共有されるため、増えるのは各worktreeの作業ファイルの分です。ただし node_modules やビルド成果物はworktreeごとに作られるので、フロントエンドのリポジトリでは依存物の容量のほうが大きくなりがちです。wtpの symlink フックやVS Codeの git.worktreeSymlinkFolders で共有するか、git.worktreeIncludeFiles でコピーするかを決めておきます。

Claude CodeやCopilot CLIなどのAIエージェントでもworktreeを使いますか？

AIエージェントの並列作業もworktreeの用途の1つです。複数のエージェントを同じフォルダで動かすとファイルの変更が混ざるため、エージェントごとにworktreeを分けて並列に作業させる使い方が広がっています。Claude Codeで並列開発する手順はClaude Codeのgit worktreeで並列エージェント開発を行う方法で解説しています。

関連記事

• Git Worktree（ワークツリー）とは｜使い方・削除(remove/prune)とsubmodule併用の注意点
• Claude Codeのgit worktreeで並列エージェント開発を行う方法｜仕組み・使い方・注意点【2026年版】
• GitHub Desktop 3.6の新機能｜worktree対応とCopilot連携強化を解説
• Sourcetreeの使い方｜インストールから認証・カスタムアクションまで
• Gitの最新バージョンは2.56.0｜確認・アップデート方法とGit 3.0の変更点【2026年10月】