worktree削除前の確認図。tracked、untracked、ignoredの3種類を別々に確認し、ignoredも保存要否を判断する。

git worktree remove前に確認する3種類のファイル:ignoredの.envは残るとは限らない

MacのGit 2.50.1でworktree作成と削除を実測。未コミット・未追跡・gitignore対象の違いと、削除前にファイル名だけ確認する手順をまとめます。Claude Codeの自動削除の検証ではありません。

git statusが空でも、そのworktreeに残したいファイルがないとは限りません。 MacのGitで使い捨てリポジトリを作って確認したところ、通常の未追跡ファイルはgit worktree removeを止めましたが、.gitignore対象の模擬.envだけがある場合は、--forceなしで削除が完了しました。

並列開発を終えてworktreeを片付ける前に、追跡対象の変更・未追跡・無視対象を分けて確認するための記事です。秘密値を表示するコマンドや、一括削除のスクリプトは使いません。

まず、対象worktreeで3つの一覧を確認する

メインの作業ディレクトリではなく、削除しようとしているworktreeに移動して実行します。以下は読み取りだけです。

# 対象の場所・ブランチを確認
git worktree list
git rev-parse --show-toplevel

# 追跡対象の変更と、通常の未追跡ファイル
git status --short --untracked-files=all

# 通常の未追跡ファイルだけ
git ls-files --others --exclude-standard

# .gitignore等で無視されているファイルも、別に確認
git ls-files --others --ignored --exclude-standard

最後の一覧には.envだけでなく、依存パッケージやビルド出力が大量に含まれることがあります。すべてを保存する必要はありません。しかし、「無視対象だから消してよい」とも判断できません。再生成できるものと、その場所にしかない設定・成果物を分けるのが確認の目的です。

これらはファイルの内容を表示しません。ただし、ファイル名自体に機密情報が入る場合もあるため、出力をそのまま公開しないでください。改行などを含む特殊なファイル名を機械処理する場合はgit ls-files -zのNUL区切りを使います。

実測:作成元の変更は、そのまま新worktreeへ移らない

2026年10月14日、Mac上の Git 2.50.1(Apple Git-155) で検証しました。独立した一時リポジトリだけを使い、ファイル内容は模擬文字列です。実際のAPIキー、業務データ、既存リポジトリは使っていません。

コミット済みのファイルを用意した後、作成元にステージ済み変更、さらに未ステージ変更、未追跡ファイル、無視対象の.envとキャッシュを置きました。新worktreeはgit worktree add --detach … HEADで作成しています。

作成元に置いたもの新worktreeで確認した結果
コミット済みのtracked.txtコミット時の内容が存在
同じファイルのステージ済み・未ステージ変更引き継がれなかった
通常の未追跡untracked.txt存在しなかった
無視対象の模擬.envとcache/存在しなかった
追跡済みの.env.example同じ内容で存在
追跡済みの.worktreeincludeファイル自体は存在したが、通常のGitコマンドによる.envのコピーは起きなかった

作成元のgit statusも操作前後で一致しました。つまり、新worktreeを作ることは、作成元にある未コミット作業やローカル設定のバックアップにはなりません。

.worktreeincludeについて確認したのは、通常のGit単体の挙動です。Claude Codeの--worktreeやフックを実行した試験ではありません。ツール側のファイルコピー機能と、Gitのcheckoutを混同しないでください。

実測:未追跡とignoredでは削除結果が違った

作成したworktreeで、次の2条件を順に試しました。

  1. 通常の未追跡ファイルonly-copy.txtを置くと、git worktree removeは失敗し、ファイルは残りました。
  2. その模擬ファイルを取り除き、.gitignore対象の模擬.envだけを置くと、同じgit worktree removeが終了コード0で成功し、worktree内の.envもなくなりました。

2の操作には--forceを付けていません。 削除拒否に頼って保存漏れを検出することはできない、というのがこの試験で得た結果です。読者の実データで削除を試す必要はありません。先ほどの読み取り一覧と保存確認までで止めて構いません。

Git公式のworktree資料は、removeが作業ツリーを削除すること、通常の未追跡ファイルや追跡対象の変更がある場合に削除を拒否することを説明しています。本記事のignoredファイルに関する結果は、上記バージョン・模擬条件での実測です。すべてのバージョンやツールによる自動クリーンアップを保証するものではありません。

削除へ進む条件を、ファイルの種類ごとに決める

  • 追跡対象の変更:必要な変更が保存され、戻せることを確認する。別worktreeがあるだけでは保存になりません。
  • 通常の未追跡ファイル:その場で作ったメモや成果物を確認する。削除エラーを消すためだけに--forceを足さないでください。
  • 無視対象ファイル:キャッシュなど再生成可能なものと、そのworktreeだけにある設定を区別する。必要なものは既存の承認済み保存方法で保管・復元確認する。秘密情報をGitへ追加して解決しないでください。

保存先が決まらない、復元できるか分からない、ほかの処理が使用中、のいずれかなら削除を見送ります。git worktree pruneは消えた作業ツリーの管理情報を整理する操作で、削除した未追跡ファイルを復元する操作ではありません。

この確認に有料ツールは必要ありません。並列開発の基本手順から進んだ場合も、作成と片付けは別の確認として扱ってください。環境ファイルを自動配布する設計はサブエージェントのworktree分離で扱っていますが、そこで紹介するツールの自動処理は今回の実測対象外です。

よくある確認

.gitignoreは削除から守る設定ですか?

追跡対象に追加しないための指定と、バックアップは別です。今回の試験ではignoredの模擬.envはworktreeと一緒に削除されました。名前だけの一覧で保存要否を確認してください。

Claude Codeが同じように消すと確認したのですか?

いいえ。実行したのはGit単体です。Claude Code、VS Code、サブエージェントの起動や自動クリーンアップは検証していません。

空のgit statusだけで削除してよいですか?

今回の条件では不十分でした。ignoredファイルの一覧、必要な変更の保存、復元可能性、処理が使用中でないことまで確認してから判断します。

参考:Git ls-files公式資料、gitignore公式資料。

← 記事一覧に戻る