競合の解決

最終更新: 2022年01月13日

なぜ競合が起きるのか

競合とは修正範囲がバッティングし、正常に作業がマージされない状態を指します。ではなぜ競合が発生するのでしょうか?

Gitは行単位で差分をチェックします。たとえば「14行目をAからBに変えた」という具合に歴史を刻んでいきます。たとえばあるサイトのタイトルの色が赤色だったとします。そのブランチから作業ブランチを作成し、CSSの14行目を赤から青に変えます。すると

作業ブランチ
14行目を赤を青に変えた

というコミットが記録されます。この状態でmasterにPullリクエストをすると、

14行目の赤を青に変えたからこの作業を取り込んでくれ

という意味になります。これは正常な状態で、正常にリクエストが飛び、マージされます。ではこのリクエストの前に他の誰かが14行目の赤を黄色に変えて、masterを変更していた場合どうなるでしょう。

14行目の赤を青に変えたからこの作業を取り込んでくれ

というリクエストに対し、Gitとしては14行目は他の人の作業ですでに黄色になっているので、意味がわからないわけです。このときに競合が発生します。つまり競合とは「AをBに変更する」というログの前提であるAが改変されている場合に発生するのです。

この場合の解決策は、

マージリクエストをする前に最新のmasterを作業ブランチに取り込む

です。競合の予防はこれにつきます。そもそも常に最新のmasterを元に作業をしていれば競合は発生しません。自分が何か作業する前に、常に最新のmasterブランチを自分の作業ブランチに取り込むことを徹底しましょう。また新たにブランチを作る際は必ずmasterを最新にしてからブランチを作成します。

今回最新のブランチを取り込めば、その時点で「前提が黄色に変わっている」ことがログとして取り込まれるので、その上で改めて色を赤に変えてコミット、プッシュ、リクエストをすれば良いのです。

競合を解決する

masterにプルリクストをした際に競合することがほとんどです。この場合、

  1. リモートの最新masterをローカルの競合したブランチにマージする
  2. 競合が発生するので解決する(エディターを使い手作業で作業を取捨する)
  3. 競合修正したらコミット、プッシュする

という手順を踏みます。

06:06で「指定元からプル」を選んでいますが、Windowsでうまくいかないケースがあるので「マージ」を選んで「origin/master」からマージしましょう。

競合解決の注意点

競合を解決する際は手作業で正しいコードを残し、いらないコードを削除します。前述の例でいうと、もしかすると黄色がそもそも正解なのかもしれません。その時に赤を正解として競合を解決すべきでありません。

競合したのが自分の書いた箇所だった場合、自分で判断してください。そうでない場合、競合するコードを書いた人に必ず確認し、お互いにどの作業を残すべきかを話し合ってから決めてください。競合はどちらかが正しいとは限らず、競合した両方の作業が必要な場合もあります。たとえば14行目で色を変える以外の変更をしている場合もあるのです。