resolving-merge-conflicts

何かに手を加える前に、状況を確認します。git status で、マージ中、リベース中、チェリーピック中のどれかを確認します。リベースでは、ours はリプレイ先のアップストリーム、theirs は自分のコミットを指し、マージの場合とは逆になります。これを取り違えることが、誤った解決の最も一般的な原因です。

次に、競合しているファイルを分類します。生成された成果物とロックファイルは、手作業でマージせず、ソースから再生成します。対象は bun.lock、pnpm-lock.yaml、_generated/、スナップショットです。手書きのファイルだけを手順 2〜3 で処理します。

各競合の一次資料を探します。それぞれの変更がなぜ行われたのか、元の意図は何だったのかを把握します。コミットメッセージを読み、PR、元の課題やチケットを確認します。

競合マーカーではなく、一次資料に照らして各ハンクを解決します。両方の意図を保ちます。両立しない場合は、マージで明示された目的に合う方を選び、トレードオフを記録します。解決後の各行は、どちらか一方の元の内容、またはその両方を機械的に組み合わせた内容にたどれるようにします。

ステージングする前に、競合している各ファイルについて、解決内容と両方の親コミットとの差分を確認します。git diff --cc <file>、または git diff :2:<file> <file> と git diff :3:<file> <file> を実行します。両側のすべてのハンクを、いずれか一つの分類に必ず割り当てます。分類は、「保持」、「置き換えた内容を記録して置き換え」、「理由を記録して破棄」です。分類できないハンクは、解決済みのふりをした黙示的な破棄であり、未解決の競合です。コミットする前に、対応記録を提示します。

必ず解決します。2 つの意図が本当に両立せず、どちらを選ぶか決める明示的な目的もない場合は、推測せずに作業を止め、解決案を 2 つともユーザーに提示します。

プロジェクトのチェックを実行します。このパイプラインは /done が担当します。受け入れレーンを選択し、それぞれを検証して状態を割り当て、レディネスカードを作成させます。そのカードで止め、最終セクションに記載された引き継ぎは行いません。マージ途中でコミットすると、マージメッセージではなく、生成された一般的な件名でマージが完了してしまうため、git-commit と file-pr は手順 5 まで保留します。マージによって壊れたものは修正します。

マージまたはリベースを完了します。すでに公開済み、または利用済みのコミットや参照を書き換える操作を行う場合は、その公開済み履歴に対する操作を続ける直前、または共有参照を更新する直前に preflight-mutations を呼び出します。操作、ローカル、アップストリーム、ベース、ヘッドの各 SHA、影響を受けるリモート参照、依存するブランチと PR、復旧用参照、明示的な書き換え許可を正確に渡します。続行する前に、その結果の契約に従います。未公開のローカルな競合解決では、このゲートを使用しません。

すべてをステージングしてコミットします。リベース中の場合は、すべてのコミットがリプレイされるまで続けます。同じ競合がリプレイされた各コミットで再発することがよくあります。すべての競合で一貫した解決を保ってください。