Git クリーンアップ

蓄積された git ワークツリーとローカルブランチを安全にクリーンアップします。ブランチを以下のカテゴリに分類します：安全に削除可能（マージ済み）、潜在的に関連（類似テーマ）、アクティブな作業（保持）。

使用する場面

• ユーザーが多くのローカルブランチとワークツリーを蓄積している場合
• ブランチがマージされたがローカルでクリーンアップされていない場合
• リモートブランチが削除されたがローカルの追跡ブランチが残っている場合

使用しない場面

• リモートブランチ管理には使用しないこと（ローカルクリーンアップのみ）
• gc や prune などのリポジトリメンテナンスタスクには使用しないこと
• ヘッドレスまたは非対話型の自動化には対応していない（ユーザー確認が2段階必要）

コアプリンシパル：安全性最優先

ユーザーの明示的な確認なしに何も削除しないこと。 このスキルはゲートされたワークフローを使用し、ユーザーが各ステップを承認してから破壊的なアクションを実行します。

重要な実装上の注意

スクワッシュマージされたブランチは強制削除が必要

重要: git branch -d は squash-merged ブランチに対しては 常に失敗します。これは git が作業が取り込まれたことを検出できないためで、エラーではなく予期された動作です。

ブランチが squash-merged として識別された場合：

• 最初から git branch -D（強制削除）を使用する計画を立てること
• 最初に git branch -d を試してから -D を求めないこと。これはユーザー確認を浪費する
• 確認ステップで、squash-merged ブランチに対して git branch -D を表示する

カテゴリ分け前に関連ブランチをグループ化

必須: 個別ブランチをカテゴリ分けする前に、ブランチ名の接頭辞でグループ化する：

# ブランチ名から共通の接頭辞を抽出
# 例: feature/auth-*, feature/api-*, fix/login-*

接頭辞を共有するブランチ（例：feature/api、feature/api-v2、feature/api-refactor）は、ほぼ確実に関連する反復です。グループとして分析する：

1. コミット日順で最古と最新を検出
2. 新しいブランチに古いブランチのコミットが含まれているか確認
3. 各ブランチの作業をマージしたプルリクエストを確認
4. 古いブランチが置き換えられているかを判定

関連ブランチをカテゴリ全体に散らすのではなく、明確な推奨とともに一緒に提示する。

徹底的なプルリクエスト履歴調査

単純なキーワードマッチングに頼らないこと。[gone] ブランチの場合：

# 1. ブランチのコミットのうちデフォルトブランチにないものを取得
git log --oneline "$default_branch".."$branch"

# 2. デフォルトブランチで この作業を取り込んだプルリクエストを検索
# 検索対象: ブランチ名、コミットメッセージキーワード、プルリクエスト番号
git log --oneline "$default_branch" | grep -iE "(branch-name|keyword|#[0-9]+)"

# 3. 関連ブランチグループの場合、どのプルリクエストがどの作業をマージしたかを追跡
git log --oneline "$default_branch" | grep -iE "(#[0-9]+)" | head -20

ワークフロー

フェーズ 1: 包括的な分析

カテゴリ分けの前に、すべての情報をあらかじめ収集する：

# デフォルトブランチ名を取得
default_branch=$(git symbolic-ref refs/remotes/origin/HEAD \
  2>/dev/null | sed 's@^refs/remotes/origin/@@' || echo "main")

# 保護されたブランチ - 分析または削除の対象外
protected='^(main|master|develop|release/.*)$'

# トラッキング情報付きですべてのローカルブランチをリスト
git branch -vv

# すべてのワークツリーをリスト
git worktree list

# フェッチしてプルーン、リモート状態を同期
git fetch --prune

# マージ済みブランチを取得（デフォルトブランチへのマージ）
git branch --merged "$default_branch"

# 最近のプルリクエストマージ履歴（squash-merge 検出）
git log --oneline "$default_branch" | grep -iE "#[0-9]+" | head -30

# 保護されていない各ブランチについて、一意のコミットと同期状態を取得
for branch in $(git branch --format='%(refname:short)' \
  | grep -vE "$protected"); do
  echo "=== $branch ==="
  echo "Commits not in $default_branch:"
  git log --oneline "$default_branch".."$branch" 2>/dev/null \
    | head -5
  echo "Commits not pushed to remote:"
  git log --oneline "origin/$branch".."$branch" 2>/dev/null \
    | head -5 || echo "(no remote tracking)"
done

ブランチ名についての注意: Git ブランチ名にはシェル展開を破壊する文字が含まれる可能性があります。常にコマンドで "$branch" をクォートする。

フェーズ 2: 関連ブランチをグループ化

個別のカテゴリ分けの前にこれを行うこと。

共有する接頭辞によってブランチグループを識別する：

# ブランチをリストし、接頭辞を抽出
git branch --format='%(refname:short)' | sed 's/-[^-]*$//' | sort | uniq -c | sort -rn

2 つ以上のブランチを持つ各グループについて：

1. コミット履歴を比較 - どのブランチが他のブランチのコミットを含むか？
2. マージ証拠を見つけ - このグループの作業をマージしたプルリクエストはどれか？
3. 「最終」ブランチを識別 - 通常、最も最近または最も完全
4. 置き換えられたブランチをマーク - 作業が main または新しいブランチにある古い反復

置き換え（SUPERSEDED）には証拠が必要で、共有接頭辞だけでは不十分:

• プルリクエストが main に作業をマージした、または
• 新しいブランチに古いブランチからすべてのコミットが含まれている
• 名前接頭辞だけでは不十分 — 同様の名前のブランチは独立した作業を含む可能性がある

feature/api-* ブランチの分析例：

### 関連ブランチグループ: feature/api-*

| ブランチ | コミット | マージされたプルリクエスト | ステータス |
|---------|---------|----------------------|---------|
| feature/api | 12 | #29 (初期 API) | 置き換え済み - main に作業あり |
| feature/api-v2 | 8 | #45 (API 改善) | 置き換え済み - main に作業あり |
| feature/api-refactor | 5 | #67 (リファクタリング) | 置き換え済み - main に作業あり |
| feature/api-final | 4 | 見つからず | 上記プルリクエストで置き換え済み |

**推奨:** 4 つのブランチはすべて削除可能 - プルリクエスト #29、#45、#67 により作業が取り込まれている

フェーズ 3: 残りのブランチをカテゴリ分け

関連グループにないブランチについて、個別にカテゴリ分けする：

デフォルトブランチにマージされているか？
├─ はい → SAFE_TO_DELETE (-d を使用)
└─ いいえ → リモートを追跡しているか？
        ├─ はい → リモートが削除されたか？ ([gone])
        │        ├─ はい → 作業が squash-merge されたか？ (main で PR を確認)
        │        │        ├─ はい → SQUASH_MERGED (-D を使用)
        │        │        └─ いいえ → REMOTE_GONE (レビュー必要)
        │        └─ いいえ → ローカルがリモートより先行しているか？ (確認: git log origin/<branch>..<branch>)
        │                ├─ はい (出力あり) → UNPUSHED_WORK (保持)
        │                └─ いいえ (出力なし) → SYNCED_WITH_REMOTE (保持)
        └─ いいえ → 一意のコミットを持つか？
                ├─ はい → LOCAL_WORK (保持)
                └─ いいえ → SAFE_TO_DELETE (-d を使用)

カテゴリ定義:

カテゴリ	意味	削除コマンド
SAFE_TO_DELETE	デフォルトブランチにマージされている	git branch -d
SQUASH_MERGED	squash merge で取り込まれた作業	git branch -D
SUPERSEDED	グループの一部、main への PR または新しいブランチで作業を確認	git branch -D
REMOTE_GONE	リモート削除、作業が main で見つからない	レビュー必要
UNPUSHED_WORK	リモートに push されていないコミットを含む	保持
LOCAL_WORK	一意のコミットを持つ未追跡ブランチ	保持
SYNCED_WITH_REMOTE	リモートと最新	保持

フェーズ 4: ダーティ状態検出

すべてのワークツリーと現在のディレクトリをコミットされていない変更についてチェック：

# 各ワークツリーパスについて
git -C <worktree-path> status --porcelain

# 現在のディレクトリについて
git status --porcelain

警告を目立つように表示:

警告: ../proj-auth にはコミットされていない変更があります:
  M  src/auth.js
  ?? new-file.txt

このワークツリーを削除すると、これらの変更は 失われます。

ゲート 1: 完全な分析を提示

すべてを 1 つの包括的なビューで提示する。関連ブランチをグループ化する：

## Git クリーンアップ分析

### 関連ブランチグループ

**グループ: feature/api-* (4 ブランチ)**
| ブランチ | ステータス | 証拠 |
|---------|---------|------|
| feature/api | 置き換え済み | PR #29 でマージされた作業 |
| feature/api-v2 | 置き換え済み | PR #45 でマージされた作業 |
| feature/api-refactor | 置き換え済み | PR #67 でマージされた作業 |
| feature/api-final | 置き換え済み | 古い反復、分岐 |

推奨: すべて削除（作業は main にあります）

---

### 個別ブランチ

**安全に削除（-d でマージ）**
| ブランチ | マージ先 |
|---------|--------|
| fix/typo | main |

**安全に削除（squash-merge、-D が必要）**
| ブランチ | マージ方法 |
|---------|---------|
| feature/login | PR #42 |

**レビュー必要（[gone] リモート、PR が見つからない）**
| ブランチ | 最後のコミット |
|---------|------------|
| experiment/old | abc1234 "WIP something" |

**保持（アクティブな作業）**
| ブランチ | ステータス |
|---------|---------|
| wip/new-feature | 5 個の push されていないコミット |

### ワークツリー
| パス | ブランチ | ステータス |
|------|--------|---------|
| ../proj-auth | feature/auth | 古い（マージ済み）|

---

**サマリー:**
- 4 つの関連ブランチ（feature/api-*）- すべて削除を推奨
- 1 つのマージ済みブランチ - 安全に削除
- 1 つの squash-merged ブランチ - 安全に削除
- 1 つはレビュー必要
- 1 つは保持

何をクリーンアップしたいですか？

明確なオプション付きで AskUserQuestion を使用する：

• 推奨されたすべてを削除（グループ + マージ済み + squash-merged）
• 特定のグループ/カテゴリを削除
• 個別にブランチを選んでください

ユーザーが応答するまで進行しないこと。

ゲート 2: 正確なコマンドで最終確認

実行される 正確なコマンド を正しいフラグで表示する：

実行するコマンド:

# マージ済みブランチ（安全な削除）
git branch -d fix/typo

# Squash-merged ブランチ（強制削除 - 作業は PR を通じて main にあります）
git branch -D feature/login
git branch -D feature/api
git branch -D feature/api-v2
git branch -D feature/api-refactor
git branch -D feature/api-final

# ワークツリー
git worktree remove ../proj-auth

確認しますか？ (yes/no)

重要: これが削除に必要な唯一の確認です。-D が必要な場合は追加の確認を追加しないこと。

フェーズ 5: 実行

各削除を 個別のコマンド として実行し、部分的な失敗が残りの削除をブロックしないようにする。各結果をレポートする：

git branch -d fix/typo
git branch -D feature/login
git branch -D feature/api
git branch -D feature/api-v2
git branch -D feature/api-refactor
git branch -D feature/api-final
git worktree remove ../proj-auth

削除が失敗した場合、エラーをレポートし、残りの削除を続行する。

フェーズ 6: レポート

## クリーンアップ完了

### 削除済み
- fix/typo
- feature/login
- feature/api
- feature/api-v2
- feature/api-refactor
- feature/api-final
- ワークツリー: ../proj-auth

### 残り（4 ブランチ）
| ブランチ | ステータス |
|---------|---------|
| main | 現在のブランチ |
| wip/new-feature | アクティブな作業 |
| experiment/old | レビュー必要 |

セーフティルール

1. 自動実行は禁止 - ユーザーが明示的に /git-cleanup を使用した場合のみ実行
2. 確認ゲートは 2 つのみ - 分析レビュー、その後削除確認
3. 正しい削除コマンドを使用 - マージ済みは -d、squash-merged/置き換え済みは -D
4. 保護されたブランチに触れない - main、master、develop、release/* （プログラム的にフィルタリング）
5. ダーティなワークツリー削除をブロック - 明示的なデータ損失確認なしに拒否
6. 関連ブランチをグループ化 - カテゴリ全体に散らさない

拒否すべき言い分

これらは一般的なショートカットで、データ損失につながります。拒否する：

言い分	間違っている理由
「ブランチが古いので、おそらく削除しても安全」	年齢はマージ状態を示しません。古いブランチはマージされていない作業を含む可能性があります。
「必要に応じて reflog から復旧できる」	Reflog エントリは期限切れになります。ユーザーは reflog の使い方を知らないことがよくあります。セーフティネットとしてこれに依存しないこと。
「ローカルブランチなので、特に重要なものはない」	ローカルブランチは、どこにも push されていない作業の唯一のコピーを含む可能性があります。
「プルリクエストはマージされたので、ブランチは安全」	Squash merge はブランチ履歴を保持しません。特定の コミットが取り込まれたことを確認すること。
「[gone] ブランチをすべて削除するだけ」	[gone] はリモートが削除されたことを意味するだけです。ローカルブランチは push されていないコミットを含む可能性があります。
「ユーザーはすべてを削除したいと思っているようだ」	常に分析を最初に提示する。ユーザーに削除内容を選ばせる。
「ブランチが main にないコミットを持つので、push されていない作業がある」	「main にない」≠「push されていない」。ブランチは main にはマージされていなくても、リモートと同期している場合があります。常に git log origin/<branch>..<branch> を確認する。