specsfy-specialist-merge-conflict-resolution

コンフリクトの解決

使用するタイミング

• git merge、git rebase、または git cherry-pick がすでに進行中で、unmerged とマークされたファイルがある場合に使用します。
• プロダクトの観点から、どのブランチの変更を採用すべきかを判断するためには使用しません。それは統合を依頼した人が決めることです。このスキルは結果となるテキストや動作を解決するものであり、ビジネス上の判断をやり直すものではありません。
• 解決後に $specsfy-specialist-code-review と組み合わせます。統合後の結果には、新しい diff と同じレビューが必要です。

フロー

1. 操作の正確な状態（merge、rebase、cherry-pick）、関係するブランチやコミット、unmerged のファイルを確認します。
2. コンフリクトのある各 hunk について、それぞれの側の意図を把握します。文字どおりのテキストだけでなく、その変更が何を実現しようとしていたかを確認します。
3. コンフリクトを分類します。テキスト上（同じ行でテキストが異なる）、構造上（同じ関数やブロックが再構成されている）、意味上（テキスト上のマーカーはないが、動作に互換性がない。例：片側でシグネチャが変更され、もう片側で呼び出し元が更新されていない）、または生成物（lockfile、ビルドファイル）です。
4. 両方の意図に互換性がある場合は、両方を維持する結果を作ります。正しい解決方法は、片側全体を選ぶことではない場合がほとんどです。
5. 意図が実際に両立しない場合は、統合の目的（統合のきっかけとなった spec／issue が求めていること）に基づいて選択し、採用しなかった案とのトレードオフを記録します。
6. すべてのコンフリクトマーカーを削除し、ファイルの構文／パースを検証して、変更したファイルに対する重点的なチェック（lint、typecheck）を実行します。
7. 操作を続行（git merge --continue／git rebase --continue）し、公開する前に関連する回帰テストスイートを実行します。

パターン

• 手間を省くために git checkout --ours／--theirs（または -X ours／-X theirs による戦略的な解決）を一括で使用しないでください。hunk ごとに正しい解決方法が異なる場合があります。全体に一律の戦略を適用すると、レビューなしに片側の実際の変更を破棄してしまいます。
• 生成ファイル（lockfile、ビルド出力、生成コード）を編集するときは、生成元も更新して再生成してください。生成ファイルを直接編集すると、次回の生成時に差分が生じます。
• 実際には衝突していない限り、両側のスキーマ変更、マイグレーション、テスト、API 契約を維持します。隣接ファイルでコンフリクトが起きていても、別のファイルのスキーマ変更を破棄してよい理由にはなりません。
• テキスト上のマーカーがないファイルでも、import、名前変更、呼び出しを再確認します。片側で名前が変更され、もう片側で古い名前の新たな使用がある場合、Git のコンフリクトにはなりませんが、実行時やビルド時に問題が発生します。
• コンフリクトを解決するために厳密に必要な範囲を超えて、新しい動作を導入しないでください。解決はリファクタリングの機会ではありません。
• 統合を進めている人から明示的に依頼されていない限り、--abort、force push、または破壊的な reset を使用しないでください。進行中の操作には、別の人がすでに行った解決作業が含まれている可能性があります。
• 操作を続行する前に、unmerged のファイルが残っておらず、インデックスがクリーンであることを最後に確認します。

アンチパターン

• 「コンパイルできる」ことだけを基準に解決すること。ファイルからマーカーは消えてビルドも通りますが、結果の動作がどちらの側の意図とも照らし合わされていません。意味上のコンフリクトが、解決済みを装って残ります。
• すでに公開され、共有されているコミットを、その上で作業している人たちと調整せずに書き換える rebase。ほかの人の履歴を気づかれないまま壊します。
• 大きなファイルのすべての hunk を個別に確認せず一度に解決すること。疲労によって誤った hunk を受け入れる可能性が高まります。
• 周辺のコンテキストが変わり、記録済みの解決が無効になっていないことを再確認せず、以前の解決を繰り返すために git rerere を信頼すること。

検証

• git status でマージ未解決のファイルがなく、作業ディレクトリ内のどのファイルにも競合マーカーの残存がないこと（作業ディレクトリで <<<<<<< を grep します）。
• 両側について再構成した意図に照らし、統合後の差分をハンクごとに確認します。
• 変更したファイルの型チェック、ビルド、重点テストを実行し、さらに統合後の動作に関連する回帰テストスイートも実行します。
• 公開前に、結果の履歴とプッシュ先（ブランチ、強制プッシュの有無）を確認します。履歴を書き換えた場合は、この確認なしに解決結果を公開してはいけません。
• その証拠なしに統合が「解決済み」と宣言してはいけません。ビルドとテストを再検証していない解決は、マーカーがなくなっただけであり、正しさが証明されたわけではありません。

関連するスキル

• $specsfy-specialist-code-review：統合後の結果を、新たな差分としてレビューする際に使用します。解決によって、元の PR を個別に見ただけでは把握できない動作が導入される可能性があるためです。
• $specsfy-specialist-domain-modeling：意味上の競合から、両側が同じドメイン概念を互換性のない形でモデル化していたことが判明した場合に使用します。競合は、境界が揃っていないことの表れです。
• $specsfy-specialist-gitflow：Gitflow を採用していると宣言したプロジェクトの feature/、release/、hotfix/ を含む競合マージ／リベースの場合に使用します。マージのトポロジーとマージ先はこのスキルが決定し、こちらはすでに発生しているテキスト上または意味上の競合を解決します。

診断コマンド、テキスト上のマーカーがない競合の種類、Git の公式情報源については、references/standards.md を参照してください。