merge conflict は、同じ場所をどう統合するか Git が自動で決められず、人が判断する必要がある状態です。 branch の merge だけでなく、rebase や git stash の pop 後にも起きます。壊れているのではなく、判断待ちになっているだけです。
まず押さえたいポイント
競合マーカーの読み方
競合したファイルには、次のような印が入ります。
<<<<<<< HEAD
今いる branch 側の内容
=======
取り込もうとしている側の内容
>>>>>>> feature/xxx
HEAD 側が「今いる場所」です。ただし rebase 中だけは HEAD の意味が入れ替わる点に注意が必要です。rebase は自分のコミットを相手の上へ積み直す操作なので、HEAD 側が取り込み先（相手）、下側が自分の変更になります。ここを取り違えて片方を丸ごと消すのが、最も多い事故です。
迷ったら中断してよい
抜けられなくなったら、いったん元の状態へ戻すのが安全です。
- merge 中 →
git merge --abort - rebase 中 →
git rebase --abort - 状況が分からない →
git statusが次に打つべきコマンドを表示してくれる
押さえておきたい注意点
競合マーカーを消しただけで終わらせると、見た目は直っていてもロジックが壊れることがあります。両方の変更に意味があるなら、片方を捨てるのではなく両方を残す形へ書き直すのが本筋です。
また、マーカーを消し忘れたまま commit する事故は git diff --check で検出できます。解消後は必ずテストか動作確認まで行ってください。
実務で見るポイント
- 競合は「長生きした branch」ほど増える。分岐したまま1週間放置すると解消コストが跳ね上がる
- 解消の判断に迷ったら、相手のコミットを
git log -pで読んで意図を確認する - merge と rebase の使い分けはgit mergeとrebaseの違いで整理しています