pr-conflict-resolve

name	pr-conflict-resolve
description	ローカルCLI（git / gh）を使ってGitHub PRのコンフリクトを解消する。merge vs rebase の戦略選択、コンフリクトマーカーの解消、安全な復旧手順、プッシュ後のPR確認チェックリストまでをガイドする。PRにコンフリクトが発生したとき、featureブランチをmainと同期するとき、コンフリクト解消後の復旧が必要なときに使う。コンフリクトを伴わないコードレビュー、PR以外の一般的なgit操作、リポジトリの初期セットアップには使わない。

PR コンフリクト解消

手順

Step 1: 安全確認

1. 作業を開始する前に、作業ディレクトリがクリーンであることを確認する:

   git status
   

   出力に "nothing to commit, working tree clean" が表示されていることを確認する。未コミットの変更がある場合は先にスタッシュまたはコミットする。
2. 現在の状態を保存するバックアップブランチを作成する:

   git branch backup-feature-branch
   

3. アップストリームの最新情報を取得する:

   git fetch origin
   

Step 2: 戦略選択

1. 作業前にチームの同期戦略を確認する。merge と rebase のトレードオフ比較マトリクスはスキル同梱の references/strategy-guide.md を読む。
2. 選択した戦略を実行する:
   • Merge（デフォルト — 共有ブランチに安全）:

     git merge origin/main
     

   • Rebase（履歴を一直線にする — 非共有ブランチ専用）:

     git rebase origin/main
     

Step 3: コンフリクト解消

1. コンフリクトしているファイルをすべて確認する:

   git status
   

   "Unmerged paths" に列挙されたファイルが解消対象。
2. 各コンフリクトファイルを開き、以下のマーカーを探す:
   • <<<<<<< HEAD — 現在のブランチの変更
   • ======= — 境界線
   • >>>>>>> origin/main — 取り込もうとしているブランチの変更
3. 双方の意図を汲み取り、最終的に正しいコードへ書き換え、3種のマーカーをすべて削除する。
4. ローカルでテストまたはビルドを実行し、ロジックが壊れていないことを確認する。
5. 解消済みの各ファイルをステージする:

   git add <解決したファイル名>
   

6. コミット前にマーカーの残留がないことを検証する。スキル同梱の scripts/check_markers.py を実行する。なければ rg で代替する:

   # スキル同梱スクリプト（推奨）
   python scripts/check_markers.py
   
   # rg が使える場合（代替）
   git diff --cached --name-only | xargs rg -l '<<<<<<<|=======|>>>>>>>' 2>/dev/null \
     && echo "マーカー残留あり — コミット前に解消すること" \
     || echo "OK: マーカーなし"
   

Step 4: コミットとプッシュ

1. Merge 戦略の場合 — マージコミットを作成する:

   git commit
   

2. Rebase 戦略の場合 — リベースを再開する:

   git rebase --continue
   

3. PRを更新するためにプッシュする:
   • Merge: git push origin <ブランチ名>
   • Rebase: git push --force-with-lease origin <ブランチ名> （--force-with-lease は自分が把握していないリモートの更新があった場合に上書きをブロックする。bare --force は使わない。）

Step 5: PR確認

1. ブラウザでPRを開く:

   gh pr view --web
   

2. UI上の "Resolve conflicts" 警告が消え、"Merge pull request" が有効になっていることを確認する。
3. "Files changed" タブを開き、意図しない空白や書式の差分が混入していないかを確認する。
4. ステータスチェック（CI/CD・lint）の状況を確認する:

   gh pr checks || true
   

   注意: checks が1件も登録されていないリポジトリでは gh pr checks が exit 1 を返すが、これはエラーではない。出力に "no checks reported" や空行のみが表示される場合は CI 未設定と判断し、次のステップへ進む。実際に失敗している場合は failing/errored のチェック名が明示される。
5. CIが一時的なエラーで失敗した場合は、GitHub UI の再実行ボタンから手動再トリガーする。
6. 非自明なロジック変更を伴う解消をした場合は、Conversation タブに調整内容のコメントを残す。
7. 既存のインラインレビューコメントと、今回の解消内容が矛盾していないかを確認する。
8. CODEOWNERS の承認が必要なリポジトリ設定になっていないかを確認し、必要なら承認を依頼する。
9. 以前に "Changes requested" が出されていた場合、解消済みになっているかを確認する。
10. Reviewers パネルの "Re-request review" アイコンから明示的に再レビュー依頼を実行する。

最小検証（30秒）

解消完了後、必ず以下の3コマンドを実行する:

# 未解決ファイル・未ステージの変更がないか確認
git status

# 直近のコミットが正しく積まれているか確認
git log --oneline -n 3

# CLIからCIチェック状況を確認（checks 未登録でも exit 1 になるため || true で継続）
gh pr checks || true

エラーハンドリング

• マーカー残留チェック（rg またはスキル同梱の scripts/check_markers.py）がマーカーを報告した場合は、対象ファイルを再度開いてマーカーを削除してからコミットする。
• マージまたはリベースを完全に中断したい場合:

  git merge --abort
  # または
  git rebase --abort
  

  どちらのコマンドも操作開始前の状態に安全に戻す。
• ブランチの状態をバックアップに完全リセットしたい場合:

  git reset --hard backup-feature-branch
  

• 誤ったコミットをすでにプッシュしてしまった場合は git reflog で履歴を確認し、安全な時点に戻す:

  git reflog
  git reset --hard HEAD@{n}
  

• .orig などの一時ファイルを誤ってステージした場合は git restore --staged <ファイル名> でアンステージし、.gitignore に追加する。
• 典型的なコンフリクトパターンの詳細と復旧手順はスキル同梱の references/conflict-patterns.md を読む。