コンフリクト

🐾 猫で例えると？

譲れない様子の2匹を、両方の変更の意図を確かめる必要がある状態に見立てています。変更履歴を管理するGitが停止して壊れたわけではなく、判断できない箇所を知らせて人の解決を待っています。

💻 アプリ・Web開発における「コンフリクト」とは？

開発現場では、主にGitやSubversionといったバージョン管理システムでソースコードを統合（マージ）する際に頻発します。例えば、エンジニアのAさんが「ボタンの色を赤にする」とコードを書き換え、同じタイミングでBさんが同じファイルの同じ行を「ボタンの色を青にする」と書き換えてしまったとします。

それぞれの環境では正常に動いていても、いざ2人のコードを1つのシステムに合流させようとした時、Gitは「同じ場所が違う内容で変更されているけど、どっちを正として上書きすればいいの？」と判断できなくなります。これがコンフリクトです。この状態に陥ると、自動での統合プロセスは中断され、人間が手動でソースコードを確認して「どちらのコードを残すか」を決定するまで先に進めなくなります。

⚠️ コンフリクトの仕組みと注意点

Gitのマージコンフリクトは、変更を自動で統合できず、人による判断が必要な状態です。むしろ「人間同士の意図のぶつかり合いを、システムが事前に検知して上書き事故を防いでくれた状態」と言えます。もしコンフリクトが起きずに勝手に上書きされてしまったら、Bさんの変更がAさんの変更を消し去る（デグレを起こす）大惨事になりかねません。

Gitにおけるコンフリクトの見え方

Gitのテキスト上の競合では、次のようなマーカーが入る場合があります。バイナリや削除・改名の競合では同じ表示にならないこともあるため、git statusでも対象を確認します。

<<<<<<< HEAD
<button class="bg-red-500">送信</button>
=======
<button class="bg-blue-500">送信</button>
>>>>>>> feature/blue-button

通常のマージではHEAD側が現在のブランチ、下側が取り込む側の変更です。ただしrebaseなどでは「自分側・相手側」の見え方が直感と異なる場合があります。意図に合う最終コードを作ってマーカーを消し、git addで解決済みを記録してから、実行中の操作に応じてマージやrebaseを続けます。

🛠️ コンフリクトを賢く使うためのポイント

変更を小さく共有し、作業内容をすり合わせると、大きな衝突を減らす助けになります。チームでは次の点を確認します。

• こまめにコミットとプッシュ（プル）を行う： お互いに毛づくろいをしてデータを同期するように、変更の差分が大きくなる前に最新の状態をローカルに取り込むことで、コンフリクトの規模を最小限に抑えられます。
• 担当領域（触るファイル）を明確に分ける： 同じ箇所を並行して変更する場合は、担当者同士で意図と作業の順番を共有します。ファイルを一切共有しないことより、重なる変更を早めに把握することが大切です。
• 片側を選ぶだけで済むか確認： 両方の変更を組み合わせたり、第三の実装にしたりする必要もあります。マーカーを消しただけで正しく統合できたとは限らないため、関係者の意図とテストを確認します。

猫同士がぶつかったときに様子を見るように、コンフリクトも両方の変更意図を確認して解消します。区切り記号を消すだけで終わらず、統合後のコードが意図した動作をするかをテストするところまでが解決です。