# squash マージ済みのブランチ / worktree を安全に消す判定手順 ## これは何の指示書か 「用済みの作業ブランチや git worktree を消したい。でも未取り込みの作業を失いたくない」 という場面で、**SHA ベースの判定を使うと必ず誤る**。その誤りの型を2つ潰し、内容ベースで 確定させるための手順。AI エージェントにそのまま読ませて実行させられる粒度で書いてある。 ## 前提 - リポジトリは **squash マージ**（GitHub の "Squash and merge" 等）を使っている。 - 掃除したいのは、過去に作った作業ブランチと、それに紐づく `git worktree`。 ## なぜ SHA 判定が壊れるのか（2つの独立した原因） **原因1: squash は祖先関係を切る。** squash マージは変更を**新しい1コミット**にまとめて main に載せる。元ブランチ先端の SHA は main の祖先に一度も現れない。したがって次はすべて「未マージ」と誤って報告する: git branch --merged # 出てこない git branch --contains # main を含まない git log origin/main..HEAD # 着地済みなのに件数が残り続ける **原因2: ローカルの `origin/main` ref が古い。** `origin/main` はリモート追跡 ref であって、リモートの現在地ではない。`git fetch` するまで 数日前のコミットを指したままになる。**内容 diff という正しい判定法を使っていても、比較対象が 古ければ答えは間違う。** この2つは重なる。実例として、ある作業ブランチを「未取り込み1件」と判定して残したが、 fetch して内容 diff を取り直したら差分ゼロ＝完全に着地済み、と結論が反転した。 ## 手順 ### 1. まず fetch する（これを飛ばすと以降が全部無効） git fetch origin main --prune `fetch` のみ。`pull` / `merge` はしない（作業ツリーを動かさないため）。 fetch 後の位置を必ず出力して、古い ref で判定していないことを示す: git log --oneline -1 origin/main ### 2. 対象ブランチが触ったファイルを確定する git show --stat --oneline ここで出たファイル一覧が、以降の diff の対象。**ファイルを絞るのが重要**で、 リポジトリ全体を diff すると main 側の無関係な前進が混ざって読めなくなる。 ### 3. 内容 diff で着地を判定する git diff origin/main -- <手順2のファイル群> - **差分が空** → 内容は完全に取り込まれている。消して安全。 - **差分がある** → まだ終わりではない。手順4へ。 ### 4. 差分が出た時の切り分け（ここを飛ばすと消せるものを残す） 差分が出ても未着地とは限らない。**merge-base 以降に main 側が独自に足した分**が 逆向きの差分として出るため。2点 diff と3点 diff を見比べて切り分ける: git diff origin/main -- # 2点: 今の main と ブランチ の差 git diff origin/main... -- # 3点: merge-base からブランチが足した差 判定の要点は **「ブランチ側が足した行が、今の main に在るか」** の一点。 - 2点 diff が **削除行だけ**（`-` のみで `+` が無い）→ それは「main にしか無い行」＝ main が後から足した分。ブランチの内容は欠けていない。**着地済み。** - 2点 diff に **追加行がある**（`+` がある）→ ブランチ側にしか無い変更が残っている。**未着地。消さない。** ### 5. 決定打を1つ取る（推奨） ブランチが**新規追加したファイル**を1つ選び、main 側の履歴を引く: git log --oneline origin/main -- <そのブランチが新規追加したファイル> squash 着地していれば、**元ブランチのコミットと同一の題名**を持つコミットが main 側に出る （多くのホスティングは題名末尾に `(#)` を自動付与する）。これは祖先関係に依らない 直接証拠になる。 ### 6. 消す前に「何を失うか」を列挙する git -C status --short 追跡外ファイル（`??`）が残っていることがある。**中身を見てから消す**: head -20 <そのファイル> git log --oneline --all -- <そのファイル> # 履歴に一度も無ければ使い捨て 一時的な指示書・生成ログなら破棄してよい。判断できないものが1つでもあれば消さない。 ### 7. 削除を実行する git worktree remove --force # 追跡外ファイルがあると --force が要る git branch -D <ブランチ名> `--force` が必要になるのは手順6で確認した追跡外ファイルがあるため。**確認せずに `--force` を 付けない**（それが手順6の存在理由）。 **リモートブランチ（`git push origin --delete`）は残す**のが既定。ローカルを消しても リモートが在れば復元できる。外向き操作でもあるので、消すなら人の承認を取る。 ### 8. 削除できたことを read-back で確かめる コマンドの exit code を成功の証拠にしない。**状態を読み戻す**: git worktree list # 対象が消えていること ls -d # "No such file or directory" になること git branch --list '<ブランチ名>' # 空行になること ## AI エージェントに投げる時の注意 - 調査と削除を**同じ指示で混ぜない**。まず読み取り専用で判定させ、結論を受け取ってから 削除を別途実行する。判定を誤ったまま削除まで走られると取り返しがつかない。 - 「`origin/main..HEAD` が N 件だから未マージ」という結論が返ってきたら、**それは根拠として 無効**と指摘して手順1から取り直させる。エージェントは SHA ベースの判定に流れやすい。 - Windows 環境ではファイル比較が改行コードで化ける。`diff --strip-trailing-cr` を使う。 ## 失敗の型（このどれかに当てはまったら手順を戻る） | 症状 | 原因 | 戻る手順 | |---|---|---| | 着地済みなのに「未マージ」 | SHA 判定を使った / fetch していない | 1 | | diff に差分が出て判断がつかない | 2点と3点を見比べていない | 4 | | 消したら追跡外ファイルが消えた | 事前に中身を見ていない | 6 | | 「消えたはず」が消えていない | exit code を証拠にした | 8 | ---