テキスト比較ツール

ハイライト表示の裏側で、diffツールはある特定のマッチング問題を解いています: 2つの行のリストが与えられたとき、両方の文書に同じ相対的な順序で現れる最長の行の並びを見つけるというものです — その共有された並びに含まれるものはすべて変更なしとされ、それ以外はすべて追加または削除としてマークされます。これが「最長共通部分列」というアイデアの背後にある発想であり、Git自身が使っているものを含め、あらゆる汎用diffアルゴリズムはこの考え方の上に成り立っています。これは一見奇妙に見える細部を説明します: 文書の下部にあったテキストの塊を上部に移動すると、単一の「移動した」操作としてではなく、通常は大きな削除と大きな追加として報告されます — アルゴリズムは共有された順序だけを探しているため、移動したブロックはその元の位置と新しい位置の両方でその順序を崩してしまうからです。

これはまた、長い行への1文字だけの編集が、行モードでは行*全体*を変更としてマークする理由も説明します: アルゴリズムは行全体を分割不可能な単位として比較するため、「1文字を除いて同じ行」と「まったく異なる行」はまったく同じように扱われます — どちらも等価性のチェックに失敗し、どちらも1行削除・1行追加としてカウントされます。これがまさに単語モードへの切り替えが役立つ状況です。単語モードは同じ発想を1段階下、行ではなく単語を照合の単位として扱う形で再実行するからです。

行モードは、行そのものが単独で意味のある単位であるものにとって正しいデフォルトです — ソースコード、JSONオブジェクト、CSVの行、ログエントリなどです。これらの形式では通常、1行が1つの完結したアイデアを表しており、特定の行が変わったこと自体が、その行の中でどの文字が動いたかとは独立して有用な情報だからです。単語モードは、意味のある単位が行より小さくなった瞬間に役立ちます: 文章の段落、契約書の条項、長い文書の中の一文などで、興味深い変更は通常たった1つの単語やフレーズであり、周囲の文はまったく同じです。そのようなテキストを行単位で比較すると、1単語の編集のために段落全体が「変更」とマークされてしまい、それは技術的には正しくても、もう一度段落全体を自分で読み直すまで実際に何が変わったのか教えてくれません。

実務上の目安: 構造化されたもの、行指向のものにはまず行モードを使い、行モードの結果で赤と緑の大きな塊がほぼ同じに見えるときに単語モードに切り替えます。そのパターンは、実際の違いが小さく、変わっていないテキストの中に埋もれている合図です。

マージ前に2つのソースコードのリビジョンを比較するのは教科書的な使い方ですが、同じ手法はコードレビューをはるかに超えて役立ちます: 稼働中のデプロイと壊れたデプロイの間でどの設定が正確に変わったかを調べるために設定ファイルの2つのエクスポートを比較する、期待していた行だけが変更されたかを確認するためにCSVエクスポートの2つのバージョンを確認する、あるいは契約書のドラフトを前のリビジョンと比較して、相手先が変更したすべての条項を、文書全体をもう一度並べて読み直すことなく見つけるなどです。これらすべてのケースにおいてdiffツールの価値は同じです — 「この2つは違うのか、違うならどこが」を、手作業での並べ読みから即座に得られる視覚的な答えに変えることです。