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 <sha>    # 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 <branch-sha>

ここで出たファイル一覧が、以降の diff の対象。ファイルを絞るのが重要で、 リポジトリ全体を diff すると main 側の無関係な前進が混ざって読めなくなる。

3. 内容 diff で着地を判定する

git diff origin/main <branch-sha> -- <手順2のファイル群>

• 差分が空 → 内容は完全に取り込まれている。消して安全。
• 差分がある → まだ終わりではない。手順4へ。

4. 差分が出た時の切り分け（ここを飛ばすと消せるものを残す）

差分が出ても未着地とは限らない。merge-base 以降に main 側が独自に足した分が 逆向きの差分として出るため。2点 diff と3点 diff を見比べて切り分ける:

git diff origin/main <branch-sha> -- <files>      # 2点: 今の main と ブランチ の差
git diff origin/main...<branch-sha> -- <files>    # 3点: merge-base からブランチが足した差

判定の要点は 「ブランチ側が足した行が、今の main に在るか」 の一点。

• 2点 diff が 削除行だけ（- のみで + が無い）→ それは「main にしか無い行」＝ main が後から足した分。ブランチの内容は欠けていない。着地済み。
• 2点 diff に 追加行がある（+ がある）→ ブランチ側にしか無い変更が残っている。未着地。消さない。

5. 決定打を1つ取る（推奨）

ブランチが新規追加したファイルを1つ選び、main 側の履歴を引く:

git log --oneline origin/main -- <そのブランチが新規追加したファイル>

squash 着地していれば、元ブランチのコミットと同一の題名を持つコミットが main 側に出る （多くのホスティングは題名末尾に (#<PR番号>) を自動付与する）。これは祖先関係に依らない 直接証拠になる。

6. 消す前に「何を失うか」を列挙する

git -C <worktree> status --short

追跡外ファイル（??）が残っていることがある。中身を見てから消す:

head -20 <そのファイル>
git log --oneline --all -- <そのファイル>   # 履歴に一度も無ければ使い捨て

一時的な指示書・生成ログなら破棄してよい。判断できないものが1つでもあれば消さない。

7. 削除を実行する

git worktree remove --force <worktree のパス>   # 追跡外ファイルがあると --force が要る
git branch -D <ブランチ名>

--force が必要になるのは手順6で確認した追跡外ファイルがあるため。確認せずに --force を 付けない（それが手順6の存在理由）。

リモートブランチ（git push origin --delete）は残すのが既定。ローカルを消しても リモートが在れば復元できる。外向き操作でもあるので、消すなら人の承認を取る。

8. 削除できたことを read-back で確かめる

コマンドの exit code を成功の証拠にしない。状態を読み戻す:

git worktree list                     # 対象が消えていること
ls -d <worktree のパス>               # "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