【Git入門】コンフリクトとは？発生原因・マーカーの読み方・解消手順を図解

前回の「Git実践・応用編」では、スタッシュ、リベース、スカッシュマージ、リバートなど、実務で役立つ操作を学びました。本記事では、複数人での開発でよく遭遇するGitのコンフリクトについて解説します。コンフリクトが起きる仕組みから、マーカーの読み方、解消の手順までを図で確認していきましょう。

https://youtu.be/dazRkaBBXXI

シリーズの全体像

このGit学習シリーズは、全部で4つの章に分かれています。

第1章ではGitの考え方を、第2章では毎日使う基本操作を、第3章では実務で役立つ操作を学びました。本記事では、最終章となる第4章の「コンフリクト編」として、競合への対応を学びます。

コンフリクトとは、Gitが変更を自動で統合できず、人の判断が必要になっている状態のことです。日本語では「競合」と呼ばれます。

コンフリクトは、エラーや故障ではありません。Gitが「どちらの変更を採用すればよいか判断できないので、決めてください」と、人に判断を求めています。

つまり、コンフリクトは「Gitからの相談ごと」と考えるとイメージしやすくなります。

コンフリクトが起きる典型的な例は、同じファイルの同じ行を、それぞれのブランチで別の内容に変更したケースです。

図では、main ブランチ側と作業ブランチ側で、greeting.txt の2行目を次のように変更しています。

同じ2行目に対して、2つの異なる変更が行われています。

この2つのブランチをマージすると、Gitは変更を自動で統合しようとします。しかし、同じ行に Hello, World と Hello, Everyone という異なる変更があるため、どちらを採用すべきか判断できません。

そこでGitは、勝手にどちらかを選ばず、コンフリクトという形で人に判断を委ねます。

コンフリクトが起きると、Gitは競合している場所に「コンフリクトマーカー」と呼ばれる目印を書き込みます。

おはよう
<<<<<<< HEAD
Hello, World
=======
Hello, Everyone
>>>>>>> feature
またね

今回のマージでは、<<<<<<< HEAD から ======= までが、いまのブランチ側の内容です。======= から >>>>>>> feature までが、取り込もうとしたブランチ側の内容です。

Gitは両方の内容を並べることで、どちらを残すか判断するように伝えています。コンフリクトマーカーは壊れた表示ではありません。

マージで発生したコンフリクトは、次の4つのステップで解消します。

第2章で学んだ add と commit は、コンフリクトの解消でも使います。基本操作の延長として流れを覚えておきましょう。

コンフリクトは、merge のときだけでなく、第3章で学んだ rebase のときにも発生します。

merge の場合
発生したコンフリクトをまとめて解消し、最後に commit して統合を完了します。
rebase の場合
コミットを1つずつ積み直すため、その途中でコンフリクトが複数回起きることがあります。コンフリクトを解消して add したあと、rebase --continue で処理を続けます。

どちらの場合も、内容を判断し、ファイルを修正して add するまでの基本的な対応は同じです。