pull-changes-resolve-conflicts

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

別のブランチ（通常は main）を現在の機能ブランチに取り込むとき、またはマージやリベース後に git status で未マージのパスが表示されたときは、このスキルを使用してください。Git ベースのチームワークフロー全般に適用できます。Flows/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 から判断できる場合は、何が異なるのかを1行で示します（例：「AlertsPage — レイアウトと新しいデータスコープ」）。

3. 編集前に分析する

以下をすべて確認します。

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

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

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

4. 推奨事項と質問（必須）

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

1. 概要の表または箇条書き — ファイル → 推奨する側、または「手動マージ」 → 理由を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（マージ）の違い： stage 2 = 現在のブランチ（HEAD）、stage 3 = 取り込まれる側（MERGE_HEAD）です。必要に応じて git checkout --conflict=merge <file> で確認します。
• フルスタックまたは Flows アプリで競合が起きやすいパス： ルートのアプリシェル、トップナビゲーション、ルートモジュール、共有の lib/ または hooks/ です。

任意のコマンドスニペットとマージメッセージのテンプレートについては、reference.md を参照してください。