Gitで修正したコードが元に戻ったので、ChatGPTと一緒に原因を追ってみた

Gitで修正したコードが突然巻き戻った。最初の仮説は「誰かが意図的に古いコードに戻したのだろう」だったが、実際に履歴を追うと違うことが分かる。修正内容は存在するのに、複数のブランチがマージされた後の最新コードには反映されていない。通常のコミットでは戻していないのに、コンフリクトすら発生していない。こういう不可解な現象はGitの仕組みそのものが正しく動いているだけで、人間の直感と食い違っているだけだ。

問題はマージコミットにあった。Gitは共通祖先から見て「どちら側だけで変更されたのか」を判定し、一方だけで変更されていれば、もう一方の値を採用する。つまり、親1で「Version=2」で変わらず、親2で「Version=1」に変わっていれば、Gitにとっては「片側だけの変更」であり、コンフリクトすら起きない。正しく動いているだけなのだ。ところが、その親2がなぜVersion=1なのか、さらに遡ると、もっと前のマージでコンフリクトを解消した時に、別の変更に紛れて古いVersion値も一緒に取り込まれていた。つまり、値が実際に巻き戻ったマージと、値を巻き戻す原因を作ったマージは別だった。

これは開発チームにとって重要な教訓だ。コンフリクト解消の際に「必要な行だけ」を選ぼうとしても、複数の変更が同じコンフリクトブロックにあれば、不要な値も一緒に取り込まれることがある。GitのBlameやTimelineだけで追うと、このパターンは見抜けない。git merge-baseやgit rev-parseで共通祖先を調べることで、初めて構造が見える。開発チームなら、なぜこの値が存在するのか、その理由まで含めてコメントを残す習慣をつけておくと、後年の調査が格段に楽になる。