コミットする前に、何を確かめるのか
前回のO-03では、変更がワーキングツリー・ステージ・コミットの3段階を経て履歴になることを見ました。では、コミットする前に、その変更が本当に自分の意図どおりなのかを、どう確かめればよいのでしょうか。ここで登場するのが差分です。この講義は、コミット前の最後の確認作業に、確かな道具を与える回だと考えてください。目で眺めて「たぶん大丈夫」ではなく、事実で確認する段階に進みます。
このスライドのポイント
- 前回O-03: 変更はワーキングツリー→ステージ→コミットの3段階で履歴になる
- では、コミットの前に「その変更が意図どおりか」をどう確かめるか
- この講義の役割: コミット前の最後の確認作業に、確かな道具を与える
差分（diff）とは何か
差分（diff）とは、2つの状態の間にある行単位の違いのことです。表示では、消えた行の先頭にマイナス、増えた行の先頭にプラスが付きます。これは、A-04からずっと「差分確認」と呼び続けてきた作業の、正式な実行手段にあたります。比較する対象は自由で、いま作業中の内容と直前のコミット、あるいはコミット同士など、見たい2点を選んで比べられます。目視の印象ではなく、変わった行そのものを突き合わせられることが、差分の力です。
このスライドのポイント
- 差分（diff）＝2つの状態の間の、行単位の違い
- マイナス（-）＝消えた行、プラス（+）＝増えた行
- A-04からずっと言い続けてきた「差分確認」の、正式な実行手段
- 比較する対象は自由（作業中と直前コミット、コミット同士 など）
なぜ差分を読む必要があるのか
差分を読めないと、AIに何を変えられたのかを、自分の記憶や目視に頼ることになります。しかしAIは、頼んでいないファイルにまで手を入れることがあります。差分を読めれば、AIの報告と実際の変更の食い違いを、機械的に見つけ出せます。依頼した範囲を超えた変更が混ざっていないかを、確実にあぶり出せるのです。この一手があるかないかで、意図しない変更を見逃す確率は大きく変わります。
このスライドのポイント
- 差分を読めない: AIに何を変えられたかを、記憶と目視に頼ることになる
- AIは、頼んでいないファイルまで手を入れることがある
- 差分を読める: AIの報告と実際の変更の食い違いを機械的に検出できる
差分表示の読み方
差分の表示には、決まった読み方があります。まず先頭のマイナス行が変更前、プラス行が変更後を表します。その前後には、変更していない行が文脈として数行付き、どこを直したのかを見失わないようにしてあります。さらに、変更のかたまりごとに、対象のファイル名が見出しとして示されます。この3点、記号・前後の文脈・ファイル名を押さえれば、差分は決して怖いものではなくなります。
このスライドのポイント
- ①記号: 先頭のマイナス行＝変更前、プラス行＝変更後
- ②前後の文脈: 変更箇所の前後に、変えていない行が数行付く
- ③ファイル名: 変更のかたまりごとに、対象ファイル名が見出しで示される
- この3点を押さえれば、差分は読める
具体例: 「色だけ」のはずが3ファイル
たとえば「ボタンの色だけ変えて」と頼んだのに、差分には3つのファイルが並んで出てくることがあります。これはまさに、A-04でお伝えした「変更していない場所はどこですか」という問いを、目で確かめている場面です。AIは「色だけ変えました」と報告するかもしれません。しかし報告は自己申告であり、抜けや思い違いが混じります。AIの自己申告よりも、diffが真実です。迷ったら、言葉ではなく差分を信じてください。
このスライドのポイント
- 「ボタンの色だけ変えて」と頼んだのに、差分に3ファイル出てくることがある
- これはA-04の「変更していない場所はどこですか」を、目で確かめている場面
- AIは「色だけ変えました」と報告するかもしれない
- AIの自己申告より、diffが真実
技術サンプル: git diff で変更を見る
サンプルは、差分を見るための2つのコマンドです。git diff は、まだコミットしていない作業中の変更を映します。git diff HEAD~1 は、直前のコミットと今の状態を比べます。どちらも表示するだけで、ファイルを書き換えたり消したりしない、読み取り専用の安全なコマンドです。出力例では、マイナスの行が元の色、プラスの行が新しい色になっているのが読み取れます。差分こそ、変更を確認するレビューの主戦場です。
混同しやすい: 変更報告 と 差分
ここで区別したいのが、AIの変更報告と差分の違いです。AIの変更報告は自己申告であり、悪気はなくても漏れることがあります。一方、差分は実際に起きた変更のすべてを、余さず映します。ですから、確認は言葉ではなく差分で行うのが原則です。報告は参考、差分が事実、と覚えておいてください。この線引きが、確認を確実な作業に変えます。
バイブコーディングでの確認点
おすすめしたいのは、AIの作業のあとに「差分を見せて」と頼み、依頼していない変更が混じっていないかを確かめてから、コミットする流れを定型にすることです。これは、A-04で学んだ差分確認の考え方を、道具で実践する完成形です。AIへの質問例としては「このdiffの中で、私が依頼していない変更はどれですか」と聞くとよいでしょう。毎回わずかな手間ですが、この一手間が、意図しない変更を本番へ持ち込む事故を防ぎます。
このスライドのポイント
- AIの作業後は「差分を見せて」→「依頼外の変更の有無」を確認、をコミット前の定型に
- これはA-04で学んだ差分確認の、道具による実践の完成形
- わずかな手間が、意図しない変更を本番へ持ち込む事故を防ぐ
一問一答とまとめ
では一問一答です。AIの変更を、もれなく確認する手段は何でしょうか。（間）答えは、差分（diff）を見ることです。AIの自己申告に頼らず、実際に変わった行を突き合わせます。30秒まとめです。差分は行単位の違いで、マイナスが消えた行、プラスが増えた行を表します。コミット前に差分で依頼外の変更を確かめる習慣が、あなたを守ります。次回は、安全に試すための分岐、ブランチへ進みます。関連資料は「Git・GitHubワード50」と「リファクタリング指示文50」です。
このスライドのポイント
- 一問一答: AIの変更をもれなく確認する手段は？
- 答: 差分（diff）を見る（自己申告に頼らない）
- 30秒まとめ: -が消えた行、+が増えた行。コミット前に差分で依頼外の変更を確認
- 次回: 安全に試す分岐＝ブランチへ
- 関連資料: 「Git・GitHubワード50」「リファクタリング指示文50」
