【Day 08】変更の確認と差分比較（status / diff）

▲ Day 08: 変更の確認と差分比較（status / diff）

👨‍🏫 専任講師からのメッセージ

受講生の皆様、お疲れ様です！ 第8回講義へようこそ。
C#で機能を実装したりバグを直している最中に、こんな経験はありませんか？
「熱中してコードを書き換えていたら、どこを修正したか分からなくなった」
「動作確認でエラーが出たが、直前に何をいじったか思い出せない」
「SVNなら svn diff で一発だったのに、Gitで git diff を叩いても何も表示されない！？」
Gitにおける「差分の確認」は、単なるコード比較ではありません。バグの混入を未然に防ぎ、壊れた箇所を瞬時に突き止めるための最重要セーフティネットです。本日は、コマンドラインでの厳密な差分把握から、TortoiseMergeによる視覚的2画面比較、そして最新のAIエージェント（Claude Code / Antigravity）を用いた差分要約とリスクレビューまで完全解説します！

① まずは現状把握！ git status の見方とスマートな短縮表示

コミットを作成する前、あるいは作業を再開する際に必ず実行すべき基本コマンドが git status です。Git管理下のファイル群が「現在どの状態にあるのか」を色分けとセクションで教えてくれます。

しかし、通常の git status は解説文が多く縦に長くなりがちです。現場のプロが愛用しているのが、短縮表示オプション git status -s（--short）です。

$ git status -s
M  src/Services/OrderService.cs      # 左が緑M: ステージング済み（コミット準備OK）
 M src/Models/User.cs                # 右が赤M: 作業ツリーで修正中（未ステージ）
MM src/Controllers/ApiController.cs  # 両方M: ステージ後、さらに作業ツリーで編集された
?? src/Helpers/CacheHelper.cs        # ??: 新規作成された未追跡ファイル (Untracked)

💡 短縮表示（-s）の2文字ルールの見分け方

• 左側の列（1文字目）: ステージングエリア（インデックス）の状態を表します。緑色の M（変更）、A（新規追加）、D（削除）が表示されます。
• 右側の列（2文字目）: 作業ツリー（ワーキングディレクトリ）の状態を表します。赤色の M や D が表示されます。

② 【最重要】git diff と git diff --staged の決定的な違い

SVNユーザーが最も混乱するのが、「git add したら git diff を叩いても差分が何も出なくなった！」という現象です。SVNの svn diff は「作業コピーとリポジトリの差分」を直接表示していましたが、Gitには「ステージングエリア」という中間バッファが存在するため、差分確認コマンドが2段階に分かれています。

▲ 【図解①】git diff と git diff --staged の決定的な違い

上の図のように、確認したい「境界線」によって使い分けます：

1. git diff

【作業ツリー ⇔ ステージング】
「まだ git add していない作業中の変更」を確認するコマンドです。ファイルを git add すると、差分はここから消えて次のステージへ移ります。

2. git diff --staged

【ステージング ⇔ 最新コミット (HEAD)】
「git add してカゴに入れた、次のコミットに含まれる変更」を確認するコマンドです。（旧エイリアス --cached も同義）。

③ C#開発者必携！ TortoiseMerge による視覚的2画面差分比較

C#のリファクタリングでは、数十行にわたるコードの並び替えやメソッド抽出、名前空間の変更などが一度に発生します。これをコンソール上の文字列（+ や -）だけで追うのは疲労と見落としの原因になります。

Windows環境では、TortoiseGitに付属する専用GUIツール「TortoiseMerge」を使用することで、極めて直感的な左右2画面（Side-by-Side）比較が可能です。

▲ 【図解②】TortoiseMergeによる視覚的差分比較（2画面比較）

TortoiseMergeの大きな利点は以下の通りです：

• 赤と緑の明確な色分け: 削除されたコードブロックはソフトな赤色、追加されたコードは緑色で明示されます。
• 行内（単語単位）の差分強調: 行全体だけでなく「どの単語・どの変数名が変わったか」を濃い色でハイライトしてくれます。
• SVNユーザーの親しみやすさ: TortoiseSVNのTortoiseMergeと全く同じUI・操作感のため、ベテランエンジニアも学習コストゼロで移行できます。

④ AIエージェントによる差分要約とコードレビュー

現代のGitワークフローにおいて、最も強力な生産性向上テクニックが「コミット直前にAIエージェントに差分を読ませてリスク診断させる」ことです。

自分一人でコードを書いていると、「意図せずデバッグ用の固定値を残してしまった」「例外処理を消してしまった」「LINQの多重評価でパフォーマンスが落ちている」といったミスに気づきにくいものです。

▲ 【図解③】AIエージェントによる差分要約とコードレビュー

【Claude Code / Antigravity用 差分レビュープロンプト】

「以下の C# コードの git diff 差分を詳細にレビューしてください。
1. 変更内容の要約（何が追加・変更・削除されたか）
2. 潜在的なバグ・デグレ（NullReferenceException、例外ハンドリングの欠落、意図せぬ副作用）
3. パフォーマンスやリソース解放の懸念事項
# git diff 出力:
[ここに差分を貼り付け]」

⑤ 実践！ 現場で即役立つ差分コマンド集

# 1. 未ステージの変更差分を確認（作業ツリー vs ステージング）
git diff

# 2. ステージング済みの差分を確認（ステージング vs 直前コミットHEAD）
git diff --staged

# 3. 特定のC#ファイルだけの差分を確認
git diff src/Services/OrderService.cs

# 4. 単語単位（word-level）で差分をハイライト表示
git diff --word-diff

# 5. 差分の全体像をコンパクトに把握（ファイル名と変更行数の統計）
git diff --stat

# 6. 直前コミット（HEAD~1）と最新コミット（HEAD）の差分を確認
git diff HEAD~1 HEAD

# 7. GUIツール（TortoiseMerge / VS Code）で差分を開く
git difftool

⚠️ 30年選手が一番ハマる落とし穴！

① 「git diff で何も出ない！」は焦る必要なし（ステージング済みを疑え）
SVNでは作業フォルダの修正が常に svn diff で見えていたため、Gitで git add を実行した直後に git diff を打って「変更が消えてしまった！？」とパニックになる方が大勢います。変更は消えたのではなくステージングエリアに移動しただけです。落ち着いて git diff --staged を叩きましょう！

② 改行コード（CRLF / LF）による「全行差分」の悲劇
WindowsでC#を書いていると、改行コードがLFからCRLFに変換されてファイル全体の全行が差分として検出されてしまう事故があります。差分確認時に git diff --ignore-space-at-eol を指定すると、改行コードや行末空白の差分を無視して純粋なロジック差分だけを検証できます。

📌 本日のまとめ＆宿題

第8回の講義、お疲れ様でした！
「作業ツリーの差分は git diff」「ステージング済みの差分は git diff --staged」「複雑なC#コードはTortoiseMergeで2画面比較」「コミット前にAIエージェントに差分を読ませてリスク診断」というプロの開発フローをマスターしました！

次回【Day 09】は、「コミット履歴の閲覧と一意な識別子（log）〜SVNのリビジョン番号とGitコミットハッシュの決定的違い〜」をお届けします。どうぞお楽しみに！