pull-changes-resolve-conflicts

変更を取り込み、マージコンフリクトを解決する

別のブランチ（通常は main）を現在のフィーチャーブランチに統合する場合や、マージまたはリベース後に git status で未マージのパスが表示された場合は、必ずこのスキルを使ってください。Git ベースのチームワークフロー全般に適用できます。Dune／React アプリでは、アプリのシェルや共有ライブラリでコンフリクトが集中することがよくあります。

目標

• 現在のブランチで意図して行われた作業を維持します。分析せずに「main を優先」または「自分たちの変更を優先」と決めつけてはいけません。
• コンフリクト解決の編集を行う前に、トレードオフをユーザーに明示します。
• 影響の大きさに沿って議論します。スタイル、文言、余白よりも先に、構造、機能、API、データモデルの変更を扱います。

厳守事項

1. 黙って解決しない — ユーザーが計画に同意する（または明示的に「推奨案を採用」と伝える）まで、コンフリクトのあるファイルから <<<<<<<／=======／>>>>>>> を削除したり、git add を実行したりしてはいけません。
2. コンフリクトが発生したら止まる — マージまたはリベースによってコンフリクトが発生した場合は、作業を一時停止して報告します。ユーザーから明示的な依頼がない限り、大きなファイルの片側を丸ごと採用して強引に解決してはいけません。
3. 影響を優先する — コンフリクトを提示するときは、次の順でおおまかに分類し、並べます。
   • P0 — 構造／プロダクト: 削除されたルート、削除されたモジュール、廃止された機能、変更されたデータまたは API の契約、SDK やスキーマの変更、認証やルーティングのシェル。
   • P1 — 振る舞い: ロジック、フック、クエリ、フィルター、エラー処理、読み込み状態。
   • P2 — UI 構造: レイアウト領域、新規または削除されたセクション、ナビゲーション。
   • P3 — 表示: トークン、余白、クラス名、文言の調整。

ワークフロー

1. フェッチして統合する（または状況を調査する）

• ユーザーがリベースを依頼していない限り、git fetch の後に git merge origin/main（または指定されたブランチ）を実行する方法を優先します。
• マージがすでに進行中の場合は、git status を実行し、未マージのファイルをすべて一覧表示します。

2. コンフリクトをユーザーに明示的に報告する

明確なリストを提示します。

• ブランチの状態: 現在のブランチ、対象ブランチ（例：origin/main）、マージかリベースか。
• 未マージのファイル: パスのみを列挙します。必要に応じて git diff --name-only --diff-filter=U を使います。
• ファイルごとの概要（簡潔に）: パスと git diff から解決せずに推測できる場合は、何が異なるかを一行で示します（例：「AlertsPage — レイアウトと新しいデータスコープ」）。

3. 編集前に分析する

次のすべてを使います。

• 会話履歴 — ユーザーやチームは、このブランチで何をリリースしようとしていましたか？
• リポジトリの情報 — 存在する場合はプロダクトやアーキテクチャのドキュメント（例：PRD.md）、現在のブランチの最近のコミット、ファイルの所有範囲（例：大規模なフィーチャーモジュールか共有 lib/ か）。
• コンフリクトのハンク — マージ中は git show :2:path（ours）と git show :3:path（theirs）を比較するか、コンフリクトマーカーを読み、変更が重複しているか、互いに独立しているかを特定します。

コンフリクトがある各領域を次のように分類します。

• 独立: 安全に組み合わせられる（例：インポートの並べ替えと新しいプロパティ）。
• 重複: どちらかを選ぶか、手動でマージする必要がある（同じ行の変更）。
• 破損リスク: ブロックが重複している（不適切なマージの後によく発生）。片側から再構築して、もう片側の意図を手動で反映する方法を推奨します。

4. 推奨案と質問（必須）

次の内容をユーザーに提示します。

1. 要約の表または箇条書き — ファイル → 推奨する側、または「手動マージ」→ 理由を一行で説明します。
2. P0 → P3 の順に並べる — 機能を削除する変更や公開動作を変更する変更を最初に取り上げます。
3. 明確な質問 — 判断が曖昧な点があれば質問します（例：「main のグローバルな動作と、ブランチのスコープ限定の動作のどちらを維持しますか？」）。
4. 方針を尋ねる — 例：「次のいずれかで返信してください：（a）推奨案に従う、（b）ファイル X はブランチ側を維持する、（c）ファイル Y は main 側を維持する、（d）マージを中止する」。

ユーザーが確認する（または明確な対応関係を指定する）までは、解決を適用してはいけません。

• 小規模で的を絞った編集を優先し、可能な限り両側の意図を維持します。
• 再度 git status を実行し、コンフリクトマーカーが残っていないことを確認します。変更した箇所について、ユーザーが重視するテストや lint も実行します。

5. ユーザーが中止したい場合

• 適切に git merge --abort または git rebase --abort を実行します。その操作の進行中の統合状態が失われることを確認します。

アンチパターン（行わないでください）

• ユーザーの承認を得ずに、リポジトリ全体で --ours / --theirs を選択する。
• main が同じファイルを変更したという理由で、機能ブランチの作業を削除して「解決」する。
• 簡潔な概要を付けずに、長いコードの中にコンフリクト一覧を埋もれさせる。
• P0 の決定を曖昧なままにして、影響の小さいスタイルのコンフリクトを先に修正する。

クイックリファレンス

• ours と theirs（マージ時）： ステージ 2 = 現在のブランチ（HEAD）、ステージ 3 = 取り込まれる側（MERGE_HEAD）です。必要に応じて git checkout --conflict=merge <file> で確認します。
• フルスタックまたは Dune アプリで競合が頻発するパス： ルートのアプリシェル、トップナビゲーション、ルートモジュール、共有の lib/ または hooks/ です。

オプションのコマンド例とマージメッセージのテンプレートについては、reference.md を参照してください。