不完全シリーズ未来予告：先祖返りの原因は3ウェイマージ(diff)を知らないから

Gitの先祖返りについての解説：失敗から学ぶ再発防止の方法

使うツールの問題ではないんです。これは。

久しぶりの予告編です。

構成管理の実務的な諸問題の多くは最近の分散系ツール(git, bzr, hg)によって、軽やかに解決されます。

しかしながら、所詮はヒトのやることですから、根本的な問題が解消されるわけではありません。

チーム開発のソース管理、構成管理にて発生する「マージミス問題」を

単なるオペミス

と捉えているなら、大いに反省すべきです。

さて、このたび書いておくべきだと思ったことの核心は以下の記事と同じです。たぶん。

3-way mergeについて調べた

• 2-wayだと片方に削除がある場合、もう片方が追加したとみなされる
  • 適切にマージできなかった場合、削除した機能が残っている。という事態になってしまう
• 3-wayだと元のファイルがあるため、それぞれの差分がわかり、自動マージでも2-wayのような事態は発生しづらい

CVSで構成管理を覚えた我々は、チーム開発においてコミットする前後で以下を確認する「癖」を身につけています。

つまり、

コミット前：

自分が作業開始した元の状態(ソースツリー)とコミットしようとする内容のdiff

自分が作業開始した元の状態と最新の状態(自分が作業している間にコミット/プッシュされたもの)のdiff

この２セットを確認しないでマージをおこなうことは自殺行為です。

gitを使おうが別のツールを使おうが、私はこの２セットを確認します。そしてコミット/プッシュ後にも確認します。

その際、3-way diff/mergeツールがあればミスが減らせます。WinMergeでも何年か前から対応していますね。

大規模開発のすそ野での開発経験のある人なら、おわかりかでしょうが、

先祖返りの問題が発覚するのは

リグレッションテストがなければ、リリース後。

という恐ろしい現実があります。

また、先祖返りが開発イテレーションの頭の方で発生したりすると、そのイテレーションの大部分のコミットが影響を受ける可能性すらあります。つまり誤ったコードベースで単体テストやコミットが繰り返されるということです。

先祖返りをピンポイントで直せば済む話ではなく

イテレーションのやり直しが必要

実務的には「無かったことにする」のかもしれませんが、時限爆弾を抱えることになるだけです。

先祖返りと気楽に書いていますが、チーム開発であれば、これは「他人のコミットを勝手に消すこと」を意味し、大規模開発であれば、「他社の成果物を勝手に削除すること」を意味します。

これがもし実体のあるモノを作ったり組み立てたりする仕事であれば、かなり深刻な事態のはずです。

おいおい

おめぇんとこの新入り

俺が溶接したところを

あっさりぶった切りやがったけど

まさかケンカ売ってんの？

というわけで、「先祖返り」を理解しないままコミット/プッシュ/プルを繰り返している能天気なみなさんが、大事故を起こす「前に」問題を把握できるネガティブナイスなエンツリーを準備中です。

つづく…

サルでもわかるGit入門【電子書籍】[ 大串 肇 ] 価格：2,200円 (2023/7/26時点)