Gitの「already used by worktree」を直す手順|作業場所を確認して安全に続ける

同じGitブランチにつながる二つの作業場所のうち、現在使用中の場所を一覧で確認する説明図

結論:「already used by worktree」や「cannot delete branch … used by worktree at …」が出たら、最初にエラーの示すworktreeの場所を確認します。そこが実在して目的のブランチを使っているなら、その場所で作業を続けるのが基本です。見えない場合だけ、外付け媒体などの未接続、手動移動、本当に削除済み、の順に切り分けます。強制切り替えや管理情報の手動削除を先に行う必要はありません。

原因は「同じブランチを別のworktreeが使用中」

Gitは、一つのローカルブランチを通常は複数のworktreeで同時にチェックアウトさせません。そのため、switchやworktree addは別の場所で使用中のブランチを拒否し、branchの削除も使用中なら止めます。これは既存の作業場所を守るための制約で、リポジトリ所有者を確認するsafe.directoryのエラーとは別原因です。

git-worktree公式資料は、一覧に各worktreeのパス、ブランチ、lockedやprunableの状態を表示すると説明しています。git-switch公式資料にも、目的の参照が別worktreeでチェックアウト済みなら通常は切り替えを拒否するとあります。本記事では、この保護を無効にする指定は解決策にしません。

まず一覧を読み、ブランチの作業場所を特定する

git worktree list --verbose

出力では、エラーに出たブランチ名と対応するパスを探します。続けてlockedまたはprunableの表示と、その理由があれば読みます。これらはGitの管理状態を示す情報であり、「人が見ても不要」と保証する印ではありません。特にパスが見えないだけで削除済みと決めないことが重要です。

一覧確認、実在確認、未接続や移動の切り分け、不要登録の点検、最終確認という五段階の説明図
使用中ブランチの場所を確認し、必要な場合だけ登録を整理して再確認する順序を示した説明図。 · 図を拡大

状態別に、既存作業を残したまま続行する

パスが実在し、目的のブランチで作業中

そのworktreeを開き、変更、未追跡ファイル、無視対象ファイルを確認します。次のパスは説明用の架空例なので、自分の一覧に表示されたパスへ置き換えます。

git -C 'C:/work/project-feature' status --short --untracked-files=all --ignored

git-status公式資料によると、通常のstatusでは無視対象は表示されません。短い形式でこの指定を使うと、未追跡は「??」、無視対象は「!!」で確認できます。必要な.envや生成物などが無視対象に含まれることもあるため、表示が空、または「clean」という説明だけで保存済みと判断しないでください。目的の作業場所なら、そこで作業を継続します。

パスが見えない

  1. 外付け媒体・ネットワーク共有が未接続:接続を戻してから再確認します。lockedに理由が表示されている場合は、その意図を読み、一律に解除しません。公式資料では、常時接続されない媒体上のworktreeを自動整理から守る用途としてlockが案内されています。
  2. ディレクトリを手動で移動した:新しい場所を確認し、worktreeのrepair機能で関連付けを直すことを検討します。古い登録を削除して作り直す前に、移動先の作業内容を確認します。
  3. ディレクトリを本当に削除し、もう不要:次のdry-runで、整理予定の管理情報を確認します。

必要な場合だけ、不要な管理情報を整理する

次の操作は何も削除せず、期限条件に当たるmissingなworktree登録を一覧にします。「now」は既定の期限を待たず候補を見るための指定で、無条件の定期掃除を意味しません。

git worktree prune --dry-run --verbose --expire now

pruneは指定した一つのパスだけを処理する操作ではありません。同じ条件に当たるmissing登録全体が対象です。未接続の媒体や移動済みのworktreeが一件でも混じるなら、通常実行へ進みません。dry-runに出た全対象が本当に不要だと確認できた場合だけ、同じ条件で管理情報を整理できます。

git worktree prune --verbose --expire now

実在するが不要なlinked worktreeは別判断

実在するディレクトリを廃止する場合は、trackedの変更、未追跡、必要なignoredファイル、残すコミットを確認してから通常のremoveを選びます。removeはworktreeのディレクトリを削除しますが、ブランチを自動削除しません。またmain worktreeには使えません。通常の実行が拒否されたとき、確認を省いて強制指定を足す手順にはしません。

git worktree remove 'C:/work/project-feature'

branch削除エラーでも、先に場所を確認する

git-branch公式資料では、linked worktreeで使用中のブランチは一覧で「+」が付き、詳細表示ではそのパスも確認できます。大文字の削除指定は未マージ判定を無視するためのもので、worktreeによる使用状態を解放する指定ではありません。Gitのbranch処理のソースでも、使用中なら「cannot delete branch … used by worktree at …」として削除処理を続けない流れです。worktreeの整理と、不要ブランチを削除する判断は分け、自動的に続けて削除しないでください。

最後に一覧を再確認する

git worktree list --verbose

目的のブランチとパスの対応が意図どおりなら完了です。既存のworktreeを残した場合はその場所で続行し、不要な登録だけを整理した場合は、元のswitchまたはaddを改めて試します。特定のブランチへ無条件に切り替えるのではなく、再確認した一覧に合わせて次の操作を選びます。

公式仕様の確認日は2026年10月8日です。

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次