行単位の差分比較が生む「静かなマージ」

Gitのマージは、共通の祖先コミットと2つのブランチの差分を行単位で比較する3-wayマージ方式で動く。公式解説書「Pro Git」によれば、異なるブランチで同一ファイルの同一部分が変更された場合に競合(コンフリクト)が発生し、手動での解決が求められる。

一方、変更箇所が互いに離れていれば、同じ機能を二重に実装する、矛盾する定数を別々の行に書き込むといった形で処理同士が衝突していても、Gitはこれを正常なマージとして処理する。テキスト上の重なりがない以上、差分計算の仕組み上、衝突を検出する手段がないためだ。自動テストが整備された環境では一部の事例はビルド失敗やテスト落ちとして表面化するが、検出されないままmainブランチに取り込まれるケースも残る。

最後の防壁はレビュー、ただし人間の認知が前提

こうしたパッチの重複を止められるのは、プルリクエストなどで行われるコードレビューのみだ。ただしレビューが機能するのは、担当者が両方のチケットの内容を把握している場合に限られる。変更同士がテキスト上は無関係に見える場合、片方のチケットしか知らないレビュアーは問題に気づけず、修正は競合の警告なしに通過する。

開発者らの間では、関連チケットの明示的なリンク、レビュアーへの事前共有、モジュール境界の整理など、競合検出を補う運用面での対策が併せて挙げられている。パッチが同一行に触れる場合にしかGitは競合を検出できず、レビューも担当者が両チケットに精通していなければ機能しない、という指摘は、概ね事実だ。