Git diffを読む：実際の変更行と文脈を区別する方法

Git diffは変更したファイル全体を再表示する代わりに、二つの状態の差を示します。赤い行と緑の行だけを追うと修正意図は見えても、比較対象や周囲のコードとの関係を見落とす場合があります。まず何と何を比較するかを決め、ファイル、変更ブロック、コードの動作という順に読むと理解しやすくなります。

本記事のコマンドと出力は説明用の例です。読者のリポジトリで実際に実行したりファイルを修正したりした記録ではありません。Git公式文書の一般的なパッチ形式を基準に説明しており、ツール、設定、マージ状況によって出力の見え方は変わり得ます。行数が少ないという理由だけで影響が小さい、または検証が終わったとは判断しません。

1. 比較対象から選ぶ

基本のgit diffは作業フォルダーとステージング領域の差を確認するために使います。git diff --stagedはステージング領域と最後のコミットの差を確認するために使います。公式のGit本が説明するように、基本のdiffが空でも最後のコミット以降の変更がすべてないという意味ではありません。

問い	コマンド例	読む範囲
まだステージしていない変更は？	git diff	ステージング領域と作業フォルダー
ステージした変更は？	git diff --staged	最後のコミットとステージング領域
現在のファイルとHEADの差は？	git diff HEAD	HEADと現在の作業内容
特定のファイルに集中するには？	git diff -- src/label.py	該当パスの基本比較

例えばファイルを修正してステージした後、再び修正したなら、同じファイルの変更が二つの範囲に分かれている場合があります。コミットする内容をレビューするにはステージした側を、まだ反映していない編集を見るには基本のdiffを読みます。問いと比較対象が違うと、正しい出力も誤って解釈してしまいます。

実行前にリポジトリの作業フォルダーと対象パスを確認します。パス例のファイルが実際のプロジェクトに存在しないなら、その名前の新規ファイルを作る必要はありません。自分のファイルパスに置き換え、出力でどの比較が行われたか読んでください。別のリポジトリの例の結果を、現在の状態の証拠には使いません。

2. ファイルのヘッダーは変更行と区別して読む

パッチにはファイルパスと変更前後のファイルを示すヘッダーがあります。一般的な形式の---と+++はファイル情報であり、三文字のマイナスとプラスをコード行の印と混同しません。通常、aとbの接頭辞は比較する二つの側を区別します。パスの移動や設定によって見え方は変わり得ます。

ファイル名の変更、新規ファイル、削除ファイルは、単なる内容修正とは異なる意味を持ちます。ファイルのヘッダーを先に見れば、どのファイルのどちら側を読んでいるか確認できます。同じ関数名が複数のファイルにある場合は、ファイルパスを見落とさないようにします。行だけをコピーした説明では、この情報が抜けやすくなります。

説明用パッチをメモする際には、コマンド、比較対象、ファイルパスを併記します。「return行を変えた」という記録より、「現在の作業フォルダーのlabel.pyでHEADと比較した変更」の方がレビュー範囲を明確にします。実際の出力にないコミット識別子を勝手に加えると、別の状態の変更のように読まれる場合があります。

3. 変更ブロックの開始行と行数を解釈する

以下は名前の文字列の前後の空白を処理するよう変更する架空のパッチです。変更ブロックのヘッダー@@ -5,3 +5,4 @@は、この例で変更前の5行目から3行、変更後の5行目から4行を扱うブロックを示します。関数より前のコード四行は、例から省略したものとします。

--- a/src/label.py
+++ b/src/label.py
@@ -5,3 +5,4 @@
 def label(name):
-    return name
+    cleaned = name.strip()
+    return cleaned
 # formatting helper

ここで実際に削除される内容はreturn nameの一行で、追加される内容は二行です。関数定義と最後のコメントはブロックを理解するための文脈です。ブロックに表示されたすべての行が修正されたわけではありません。変更前後の行数には、それぞれの側に対応する文脈も含まれます。

ブロックの開始行が変わる場合も、その意味を別途確認する必要があります。前方の変更で後方のコード位置が移動すると、同じ論理的位置が別の行番号として見える場合があります。行番号の差を直ちに別の機能変更と読まず、該当する関数と周囲の条件を併せて確認してください。空行が文脈に含まれる場合もあります。

4. プラス・マイナス・文脈を実際の動作に結び付ける

上のパッチでは、従来の文字列をそのまま返す動作から、前後の空白を整理した文字列を返す動作へ変わります。変更行を読んだ後に「どの入力で結果が変わるか」と問えば、レビューが具体的になります。空白のない名前は同じ結果かもしれませんが、両端に空白がある入力は変化する構造です。

だからといって、この変更が無条件に良いわけではありません。入力の空白を保存する必要がある分野なら、要件に合わない可能性があります。また関数が文字列以外の入力も受け取るなら、その条件を確認する必要があります。diffは意図を示す資料であり、実際の要件を決める文書ではありません。

説明用の入力条件	レビューの問い	必要な根拠
前後に空白なし	従来の結果が維持されるか？	正常入力の比較
前後に空白あり	削除することが要件か？	入力規則と期待される結果
空文字列	空の値の動作を維持するか？	境界入力の確認
文字列以外の値	許可するか拒否するか？	呼出し条件と入力契約

表の答えは実際のプロジェクトで埋める必要があります。コード一行を目で読んだことと、プログラムを実行して結果を確認したことは異なります。レビューメモにコードから予想した影響と実際の検査で確認した影響を分けて記すと、他の人が証拠の範囲を理解しやすくなります。

5. まず一覧を見て重要なファイルから読む

変更が多い場合はgit diff --statでファイルごとの概要を確認したり、git diff --name-onlyでファイル名を確認したりできます。この出力はレビューするファイルを選ぶための案内であり、関数の動作を説明するパッチ全体の代わりにはなりません。概要に含まれない詳細は、そのファイルのdiffで確認します。

架空の変更群に入力処理ファイル、検査ファイル、文書ファイルがあるとします。まず動作を変える入力処理ファイルを読み、その動作を確認する検査ファイルを照合します。最後に文書が同じ規則を説明するか確認できます。名前だけ変わったファイルと実行経路を変えたファイルを、同じ影響として数えません。

ステージ内容をレビューするなら、一覧コマンドにも同じ比較条件を付ける必要があります。基本範囲の一覧とステージ範囲のパッチを混ぜると、別の変更同士を結び付けてしまう場合があります。一つのレビュー記録で比較基準を維持することは、ファイル数を減らすことより重要です。

6. 空の出力と大きすぎる出力の理由を探す

出力がない場合は、まず比較対象を確認します。ステージした変更だけが残っていれば、基本のdiffは空の場合があります。新しく作った未追跡ファイルも、基本のdiffの変更だけを見てすべて確認したとは仮定しません。作業状態とパスを併せて調べ、何が比較に含まれたか確認してください。

逆にファイル全体が変わったように見える場合は、実際のロジック修正か、書式や行末の差かを調べます。このとき「見づらいから全部無視する」と、意味のある空白変更も見落としかねません。確認したい問題が表示の差か機能の差かを分け、最終レビューには必要な元の変更内容を残します。

バイナリファイルやマージの複合diffは、一般的な一方のプラス・マイナス形式だけですべて解釈できるわけではありません。見慣れた例と形が違う場合は、公式文書の該当出力形式を確認してください。画像ファイルの内容をテキストパッチのように読んだり、複数の親の変更を単一比較と断定したりしません。

7. レビュー結果を修正依頼に変える

修正が必要ならファイル、変更ブロック、影響を受ける入力、期待する規則を併せて提示します。「この部分が変だ」より「空白を保存すべき入力にもstripが適用されるため、その条件を区別する必要がある」の方が具体的です。コードから読み取った候補か、実際の失敗を確認した問題かも明示する必要があります。

検査ファイルも変更されたなら、期待値を変えて検査を通しただけか、実際の要件変更を反映したかを調べます。失敗した検査を削除したなら、その条件が不要になった理由も確認してください。検査行が追加された事実だけでは、修正の正しさは保証されません。

レビュー後は比較対象、確認したファイル、主要な動作変更、実際の検証範囲、残った問いを短く記録します。同じdiffを再び読む人が、何を確認すべきか分かる情報を目指します。変更を戻したりコミットしたりする前に、ユーザーの別の編集も含まれていないか照合します。

8. 読者がすぐ使える読み方の順序

最初にコマンドが比較する二つの状態を書き、ファイル一覧を見ます。ファイルのヘッダーで対象と種類を確認し、次に変更ブロックの範囲を読みます。プラスとマイナスの内容から入力・出力・副作用がどう変わるか考え、文脈から呼出し条件を確認します。最後に関連する検証根拠を照合してください。

この順序はパッチを理解する方法であり、実行成功やデプロイ承認を意味しません。一行の変更でも複数の呼出し箇所へ影響する場合があり、大規模な書式変更でも動作はそのままの場合があります。ファイル数や行数よりも、要件と実際の結果のつながりを基準にレビューすれば、Git diffを有用な判断資料として使えます。

公式出典と執筆基準

• Git：git-diff文書
• Pro Git：リポジトリへの変更の記録

資料確認日：2026-10-06。実際に開いた公式資料に基づきAIが作成した説明です。別途示した計算・コード・確認事例は説明用であり、ユーザー環境を直接試験したり実測したりした結果ではありません。公開準備段階で機能と公式資料の変更有無を再確認しました。