Git のマージ競合

競合は通常、2 人の人間がファイルの同じ行を変更したとき、またはある開発者が編集しているファイルを別の開発者が削除したときに発生します。このような場合、Git では何が正しいのかを自動的に判断することができません。競合の影響を受けるのはマージを実行している開発者だけであるため、チームの他のメンバーが競合に気付くことはありません。Git は競合が発生しているファイルにマーキングを付けてマージ処理を停止します。ここで競合を解決するのは開発者の役割です。

マージの競合を現実に近い形で理解するために、次のセクションでは競合を意図的に作成して、それを調べたうえで解決します。サンプルでは Unix 形式のコマンドライン Git インターフェースを使ってサンプルのシミュレーションを実行します。

このコードサンプルでは以下を達成するコマンドシーケンスを実行しています。

• git-merge-test という名前の新しいディレクトリを作成し、そのディレクトリに変更して新しい Git リポジトリとして初期化する。
• 新しいテキスト ファイル merge.txt を作成してその中にコンテンツを入れる。
• merge.txt をリポジトリに追加してコミットする。

これで、main というブランチと、コンテンツが入ったファイル merge.txt がある新しいリポジトリができました。次は、新しいブランチを作成して競合するマージとして使用します。

上記のコマンドシーケンスでは以下を実行します。

• new_branch_to_merge_later という名前の新しいブランチを作成してチェックアウトする
• merge.txt のコンテンツを上書きする
• 新しいコンテンツをコミットする

new_branch_to_merge_later という新しいブランチで merge.txt のコンテンツを上書きするコミットを作成しました。

この一連のコマンドは、main ブランチをチェック アウトして merge.txt にコンテンツを追加してコミットします。これで、サンプル リポジトリに 2 つの新しいコミットがある状態になりました。main ブランチと new_branch_to_merge_later ブランチに、それぞれ新しいコミットが 1 つずつあります。今回は git merge new_branch_to_merge_later を実行して、何が起きるかを見てみましょう。

競合が発生しましたが、Git のおかげでそれがわかりました。

前のサンプルからわかるとおり、競合が発生したことを説明する出力が Git から生成されます。git status コマンドを実行して、さらに詳細を確認できます。

git status の出力から、競合が原因でマージされていないパスがあることがわかります。merge.text ファイルのステータスが編集済みになっています。ファイルを調べて何が編集されたのか見てみましょう。

ここでは cat コマンドを使って merge.txt ファイルのコンテンツを取り出しました。追加されます。不自然なものが追加されているのがわかります。

• <<<<<<< HEAD
• =======
• >>>>>>> new_branch_to_merge_later

これらの新しい行は「競合の境目」を表しています。======= の行は競合の「真ん中」を表しています。中心と <<<<<<< HEAD 行の間にあるすべてのコンテンツは、HEAD ref が参照している現在のブランチ main に存在するコンテンツを表しています。一方、中心と >>>>>>> new_branch_to_merge_later の間にあるすべてのコンテンツは、マージしているブランチに存在しているコンテンツです。

マージの競合を解決する最短の方法は、競合が発生しているファイルの編集です。いつも使っているエディターで merge.txt ファイルを開いてみましょう。今回のサンプルでは競合の原因をすべて削除します。そうすると merge.txt のコンテンツは次のような状態になります。

ファイルの編集が完了したら、git add merge.txt を使って新たにマージされたコンテンツをステージングします。マージを完了するには以下を実行して新しいコミットを作成します。

Git では競合が解決したとみなされ、新しいマージコミットが作成されてマージが完了します。

Git を操作するときとマージ中にステータスコマンドを使うと競合が発生しているファイルを特定できます。

--merge 引数を git log コマンドに渡すと、マージ対象のブランチ間で競合しているコミットの一覧を含むログが生成されます。

diff を使うとリポジトリ/ファイルの状態間の差分を生成できます。これはマージの競合を予測して防止するのに便利です。

checkout を使ってファイルへの変更を元に戻したり、ブランチの変更に使ったりできます。

reset を使って、作業ディレクトリとステージング エリアの変更を元に戻せます。

--abort オプションを指定して git merge を実行すると、マージ処理を終了してブランチをマージ開始前の状態に戻します。

マージの競合が発生しているときに git reset を使って、競合しているファイルを問題のなかった状態にリセットできます。

マージの競合はときにやっかいな問題になります。ただ、Git には競合を特定して解決するための強力なツールが用意されているので、心配はいりません。Git では独自の自動マージ機能で大半のマージに対応できます。2 つの異なるブランチでファイルの同じ行に編集を加えた場合、または一方のブランチではファイルを削除してもう一方のブランチではそのファイルを編集した場合に競合が発生します。チームで作業に取り組むような環境では競合が発生する確率が非常に高くなります。

マージの競合を解決できるツールはたくさんあります。Git にはここで説明したように多数のコマンド・ライン・ツールがあります。これらのツールの詳細については、git log、git reset、git status、git checkout、git reset の各ページを参照してください。Git 以外にも最新のマージ競合サポート機能を備えたサード・パーティ製ツールがあります。