Tech Learning Daily

2 つの版を見比べるだけでは決められない

マージは「2 つのファイルの差分を取って混ぜる」作業のように思える。しかし 2 つだけでは判定できない場面がすぐに出てくる。main では timeout = 10、feature では timeout = 30 になっているとき、どちらが新しい値なのかは 2 つの版を眺めても分からない。main が 30 から 10 に変えたのかもしれないし、feature が 10 から 30 に変えたのかもしれない。

この曖昧さは、元の値が分かれば消える。元が 30 なら「main だけが変えた」ので 10 を採ればよい。そこで git は、2 つのブランチが分岐した地点のコミットをもう 1 つの比較対象として持ち出す。これがマージベース（2 つのコミットに共通する祖先のうち、最も新しいもの）だ。

以前の記事で見たとおり、git のコミットは差分ではなくスナップショット全体を指している。だからマージのたびに、git はマージベースのスナップショットを起点として「ours（今いるブランチ）がどう変えたか」「theirs（取り込むブランチ）がどう変えたか」という 2 本の差分をその場で計算する。マージベースは git merge-base main feature で確認できる。

     マージベース (base)
     timeout=30, log=info
       ┌──────┴──────┐
       ▼             ▼
  main (ours)    feature (theirs)
  timeout=10     timeout=60
  log=debug      log=info
       └──────┬──────┘
              ▼
     マージ結果: log=debug
     timeout は衝突 → 人間へ

3-way マージの判定ルール

3-way マージ（base・ours・theirs の 3 つを突き合わせて結果を決める方式）の規則は、ファイルの領域ごとに次の 4 通りしかない。base と ours が同じなら theirs を採る。base と theirs が同じなら ours を採る。ours と theirs が同じ内容に変わっていれば、それを採る。3 つとも違うときだけ、git は機械的に選べないのでコンフリクトとして人間に返す。

git の公式ドキュメントもこの動作を「共通祖先からの変更のうち、重ならないもの（片側がある領域を変え、もう片側はその領域に触れていない）はそのまま結果に取り込まれる」と説明している。数十行の変更がほぼ自動で混ざるのは、2 人の変更がたいていファイルの別々の場所に散らばっていて、上の最初の 2 規則で片付くからだ。

ここで素朴な予想が 1 つ外れる。「違う行を編集していれば衝突しない」と考えがちだが、git は隣り合う行への変更も同じ領域への変更とみなしてコンフリクトにする。9 行目を ours が、10 行目を theirs が書き換えると、間に無変更の行が 1 行も挟まらないため 2 つの差分が 1 つの塊になる。git のメーリングリストでは、隣接する行はコードでは 1 つの振る舞いを構成していることが多く、人間に確認させる方が安全だという設計判断として説明されている。

コンフリクトマーカーの読み方と diff3 / zdiff3

コンフリクトした領域は、作業ツリーのファイルにコンフリクトマーカー（<<<<<<<・=======・>>>>>>> で両側の内容を囲んだ印）付きで書き出される。======= より上が ours、下が theirs だ。ただしデフォルトのスタイル merge は base の内容を表示しないので、2 人がそれぞれ何を変えたのかは推測するしかない。

設定 merge.conflictStyle を diff3 にすると、||||||| の行に続けて base の内容も表示される。zdiff3 は diff3 と同じ情報に加え、領域の先頭と末尾で両側が一致している行をマーカーの外へ出して、衝突範囲を狭く表示する。

git config --global merge.conflictStyle zdiff3

この設定を入れていないと、例えば ours が値を 10 に、theirs が 60 に変えた衝突で「元は 30 だった」ことが画面に出ず、ours が「下げた」のか theirs が「上げた」のかを判断できない。base が見えれば、両者の意図（片方は短くしたい、片方は長くしたい）を読んで第 3 の値に落とす判断ができる。

マージが止まっている間、3 つの版はインデックス（次のコミットの中身を組み立てる領域）にステージ番号付きで保存されている。ステージ 1 が base、2 が ours（HEAD）、3 が theirs（MERGE_HEAD）で、git show :1:app.conf のように取り出せる。設定を後から変えた場合でも、git checkout --conflict=diff3 app.conf でマーカーを base 付きに書き直せる。

コンフリクトが出なかった ＝ 正しい、ではない

3-way マージの判定は行のテキストだけを見ている。そのため、ours が関数 fetch_user を find_user に改名し、theirs が別ファイルに fetch_user の新しい呼び出しを足すと、行としては一切重ならないのでマージは綺麗に成功し、結果のコードは壊れる。こうした意味上の衝突は git には検出できず、マージ後のコードでテストやビルドを走らせて初めて見つかる。

2 つのブランチが互いのマージを何度も取り込み合うと、マージベースの候補が 2 つ以上になることがある（criss-cross マージ）。現在のデフォルト戦略 ort は、この場合に複数の共通祖先をいったん合成した仮想的な base を作り、それを基準に 3-way マージを行う。ort は Git 2.34 からデフォルトで（それ以前の recursive は v2.33.0 までのデフォルト）、v2.50.0 以降は -s recursive を指定しても ort が使われる。