DESIGN / CODE / INFRA / AI

解説

AIが直したコード、どこが変わった?git diffで確認する手順

AIの修正を受け取ったら、git statusとgit diffで変更範囲を確認しよう。未追跡・未ステージ・ステージ済みの違いを、一時リポジトリで動かせる作例付きで解説するよ。

AIが直したコード、どこが変わった?git diffで確認する手順

AIにコードの修正を頼んだあと、「直ったらしいけれど、どこまで変わったんだろう」と迷うことはないかな。

そんなときは、完成した画面だけでなく変更されたファイルと差分を確認するところから始めよう。Gitなら、git statusとgit diffを組み合わせて、未追跡・未ステージ・ステージ済みを分けて見られるよ。

最初にgit statusで全体を見る

プロジェクトのルートで、まずは次を実行する。

git status --short

??は未追跡ファイル。AIが新しいスクリプトや設定を作った場合は、ここに出ることがある。git diffの表示が空でも、未追跡ファイルがないとは限らないんだ。

短いstatus表示は左と右の列でステージ済み・作業ツリーの状態を表す。位置を詰めて読まず、スペースを含めて見るのがポイントだよ。最初は通常のgit statusも併用すると分かりやすい。

git diffとgit diff --cachedは比較する場所が違う

コマンド 通常の比較対象 何を確認する?
git diff インデックスと作業ツリー まだステージしていない変更
git diff --cached HEADとインデックス 次のコミットに入る変更
git diff HEAD HEADと作業ツリー ステージ済み・未ステージを合わせた追跡ファイルの変更

ここでのインデックスは、コミットする内容を準備する場所。git addしたあとに通常のgit diffが空になるのは、変更が消えたからではなく、比較している場所が変わったためだよ。

未追跡ファイルの内容は、この表のコマンドだけでは一覧できない。statusでファイル名を把握して内容を開き、コミット対象にするものだけを明示的にステージしよう。

未ステージの変更はgit diff、ステージ済みの変更はgit diff --cachedで確認する整理図

通常の作業ツリーを想定した比較関係。未追跡ファイルは別に確認するよ。

小さい作例でステージ前後を比べる

既存のプロジェクトを触らず、mktempで作る新しい一時フォルダで試そう。GitとBashがある環境向けの例だよ。リポジトリ名や設定値は説明用のものにしている。

demo_dir=$(mktemp -d)
git init -q "$demo_dir"
cd "$demo_dir"

printf 'theme=blue\n' > settings.txt
git add settings.txt
git -c user.name='Example' -c user.email='example@example.invalid' \
  commit -qm 'Initial example'

printf 'theme=gold\n' > settings.txt
printf 'Review this new file\n' > review-notes.txt

git status --short
git diff -- settings.txt

この時点では、settings.txtのblueからgoldへの変更がdiffに出て、review-notes.txtはstatusで未追跡として見つかる。続いて、追跡済みの設定ファイルだけをステージするよ。

git add settings.txt
git diff -- settings.txt
git diff --cached -- settings.txt

通常のdiffは空になり、--cached側に同じ変更が出る。この順序を、Git 2.52.0の一時リポジトリで実行して確認したよ。作例はダウンロード用スクリプトにもまとめている。スクリプトは自分で作った一時フォルダを残すので、確認後に表示された場所を整理してね。

AIの修正を見るときの確認順

1. ファイル名と変更量を先に見る

git diff --stat
git diff --cached --stat

依頼した箇所以外の設定、依存パッケージ、ロックファイル、デプロイ処理が変わっていないか確認する。変更行数が少なくても認証や権限に影響することはあるので、量だけで安全と判断しないでね。

2. 対象を絞って本文を読む

git diff -- path/to/file
git diff --cached -- path/to/file

--の後ろは確認したいパス。削除された条件、追加された例外処理、ログ出力、外部への通信、ファイルへの書き込みなどを順に追おう。

自分で理解できない変更があれば、AIに「この差分が何を変え、どの条件で動くかを説明して」と頼める。ただし、その説明もコードとテストで確認する。AI自身の説明だけを、修正が正しい根拠にはしないよ。

3. 空白の問題と、動作の問題を分ける

git diff --check
git diff --cached --check

--checkは、追加行の末尾空白など、Gitが判定する空白エラー等を見つけるためのもの。作例では末尾空白を加えると非ゼロ、除くと0で終了することも確認した。

構文や業務ロジック、情報漏えい、性能の検査ではないので、プロジェクトのテストやビルドも実行しよう。たとえば修正した入力条件、失敗時の処理、既存の主要な操作を確認し、どのテストが何件実行されたかも見ると、確認漏れを探しやすいよ。

コミット直前にもう一度見る

最後はgit statusで対象を確認し、ステージ済みの差分を読み直そう。AIが作った一時ログ、実際の鍵、不要な生成物まで混ざっていないかも確認する。

未追跡ファイルと.gitignoreの関係は、追跡済みファイルとの違いへ。AIの回答自体を比較したい場合は、AI出力の評価表も使ってみてね。

「AIに任せる」と「差分を見ない」は別の選択。作業を任せたぶん、変更の範囲と確認結果を短く把握できる状態にしておこう。

参考・出典

みんなのコメント 0

感想や、試してみたことを聞かせてね。コメント・返信は承認後に公開されます。

最初のコメントをどうぞ。