「git addしたファイルの中身、ちゃんと意図したものになっているか?」——コミット直前にステージング済み(add済み)の変更を確認するのは、レビュー可能な履歴を作るうえで欠かせない習慣です。実は素のgit diffではadd済みの変更は見えません。git diffは「作業ツリー vs index」を表示するため、addした瞬間に差分がゼロになってしまうためです。
この記事では、add済み(staged)の内容を確認するコマンドを体系的にまとめます。git diff --cached/--stagedの正しい使い方、3種類のdiffビューの違い、要約表示(--stat)、ワード単位比較(--word-diff)、GUI/IDEでの確認、そして特定ファイルのindexスナップショットを直接覗く方法まで、コミット前レビューに役立つ実務テクニックを解説します。
この記事で学べること
- Gitの3層構造(作業ツリー/index/HEAD)と3種類のdiffビュー
git diff --cached/--stagedでadd済みの変更だけを確認する方法- ファイル一覧だけ・統計だけ・ワード単位などの表示バリエーション
git show :FILEでindexのファイル内容を直接確認する方法- VS Code/IntelliJ/SourceTree/
git difftoolでのGUI確認 - バイナリ・大容量ファイル・改行コード変更など特殊ケースの見方
- コミット前レビューの具体的ワークフロー
まず押さえる:diffが比較する3つの場所
Gitでは作業ツリー/index/HEADという3つの状態があり、git diffはオプション次第で比較対象が変わります。「addしたファイルの変更を見たい」には、適切な比較対象を選ぶ必要があります。
結論:add済みの変更を確認したいならgit diff --cached(または同義の--staged)を使います。--cachedが古い慣例名、--stagedが新しめの別名で、機能は完全に同じです。見やすさの好みでどちらを使ってもかまいません。
よくある誤解:素のgit diffで「addしたはずの変更が見えない」と困る人が多いですが、これは仕様です。git diffは未addの変更を見るコマンドで、addしてしまうとそのファイルの差分はゼロになります(作業ツリーとindexが一致したため)。add済みを見たいときは必ず--cachedを付けてください。
基本:git diff –cached で add済みの変更を見る
もっともよく使うパターンです。git statusで「Changes to be committed」に入っている変更を具体的にどう書き換わったか確認できます。
# add済みの全変更をdiff表示 git diff --cached # --staged は完全同義のエイリアス git diff --staged # 特定のファイルだけ git diff --cached src/auth.py # 複数ファイル git diff --cached src/auth.py src/utils.py # ディレクトリ配下 git diff --cached src/
出力の読み方
diff --git a/src/auth.py b/src/auth.py
index 70a633d..7972012 100644
--- a/src/auth.py ← 変更前(index ≒ HEAD側)
+++ b/src/auth.py ← 変更後(作業ツリー側)
@@ -10,6 +10,7 @@ ← 変更箇所の行範囲(ハンクヘッダ)
def authenticate(user):
token = generate_token(user)
- return token
+ logger.info(f"auth ok: {user.id}")
+ return {"token": token, "expires": 3600}
diff出力の色分け(端末)
- 赤(
-行):削除された行 - 緑(
+行):追加された行 - シアン(
@@行):ハンクヘッダ(変更位置) - 色がつかない場合:
git config --global color.ui autoで有効化
表示バリエーション:用途別の見せ方
ファイル一覧だけ確認したい
# addされたファイル名だけをリスト git diff --cached --name-only # 出力例: # src/auth.py # src/utils.py # 変更種別(A=追加/M=変更/D=削除/R=rename)付き git diff --cached --name-status # 出力例: # M src/auth.py # A src/new_feature.py # D src/obsolete.py
規模感だけ把握したい(統計)
# ファイル別の変更行数を表示 git diff --cached --stat # 出力例: # src/auth.py | 10 +++++++--- # src/utils.py | 5 ++++- # 2 files changed, 12 insertions(+), 3 deletions(-) # サマリー行だけ git diff --cached --shortstat # 出力例: # 2 files changed, 12 insertions(+), 3 deletions(-) # ファイル種別変更などのサマリー git diff --cached --summary
ワード単位で差分を見たい
# 単語単位の差分(日本語でもスペース区切りなら動く) git diff --cached --word-diff # 表示色を付ける git diff --cached --word-diff=color # マークダウン・コード以外の自然言語文書に便利
ポイント:長い英文や文書ファイルは行単位diffだと読みづらいものです。--word-diffなら「どの単語が置き換わったか」だけ視覚化できます。コードは--word-diff-regex='\w+'で識別子単位にすると読みやすくなります。
空白・改行コード変更を除外したい
# 末尾空白を無視 git diff --cached --ignore-space-at-eol # 空白の量を無視 git diff --cached -w git diff --cached --ignore-all-space # 空行追加/削除を無視 git diff --cached --ignore-blank-lines # 改行コード変更(CRLF/LF)を無視 git diff --cached --ignore-cr-at-eol
文脈行の増減
# 前後10行ずつ表示(既定は3行) git diff --cached -U10 # 文脈なしで変更行のみ git diff --cached -U0
indexのファイル内容を直接覗く
差分ではなく「addした結果のファイル全体」を見たいケースもあります。ステージ済みの状態を具体的に把握したいとき便利な方法を紹介します。
# index にある状態の file をそのまま出力 git show :src/auth.py # :0 は「index」「ステージ0」を指す(通常のstaged) git show :0:src/auth.py # HEAD と index と作業ツリーの3者を同時比較 git diff HEAD -- src/auth.py # HEAD ↔ 作業ツリー git diff --cached -- src/auth.py # HEAD ↔ index git diff -- src/auth.py # index ↔ 作業ツリー # indexのファイル一覧(パーミッションやハッシュ付き) git ls-files --stage src/
コンフリクト時のindex(ステージ番号)
:0:file:マージ時の「解決済み」版:1:file:共通の祖先(base):2:file:マージ元(ours):3:file:マージ先(theirs)
通常の単純なaddでは:0:file=:fileが等価です。コンフリクト発生時にはステージ1〜3が埋まり、それぞれの版をgit showで確認できます。
GUI・IDEでstaged差分を確認する
CLIに慣れないメンバーや、カラフルな視覚的確認が欲しいときはGUI/IDEが便利です。
主要ツールでのstaged表示
- VS Code / Cursor:Source Controlパネルで「STAGED CHANGES」配下のファイルをクリック→diffビュー
- JetBrains(IntelliJ/WebStorm):Commit Windowで「Changed Files」→ファイル選択→Diffペインが自動更新
- GitHub Desktop:Changesパネルで各ファイルをクリック→右側にdiffが表示
- SourceTree:Staged filesを選択→下部にdiffビュー
- tig(CLIツール):
tig statusでstaged/unstagedの対話的表示
お好みのdifftoolで比較する
# デフォルトのdifftoolを起動(要設定) git difftool --cached # 特定ツールを指定(VS Code例) git difftool --cached --tool=vscode # tool設定例(~/.gitconfigに追記) # [diff] # tool = vscode # [difftool "vscode"] # cmd = code --wait --diff $LOCAL $REMOTE
ポイント:画面共有でレビュー相手にdiffを見せるときはGUIが圧倒的に伝わりやすいです。普段のセルフレビューはCLI、ペアレビューやリモート説明はGUIと使い分けるのが実務的です。
実践シナリオ
シナリオ① コミット直前の最終確認
# まずファイル数・規模を俯瞰 git diff --cached --stat # 次に各ファイルの内容を精読 git diff --cached # ファイル別に確認したい場合 git diff --cached src/auth.py # 問題なければコミット git commit -m "feat: トークン発行時にログ出力を追加"
習慣化のすすめ:git commit前に必ずgit diff --cached --stat+git diff --cachedの2段階確認を挟むと、「あ、このprint文消し忘れた」「デバッグ用のコメントアウトが残っていた」といった軽微なミスを捕まえられます。レビュアーの時間も節約できます。
シナリオ② 大量addした直後の洗い出し
# 変更ファイルを一覧 git diff --cached --name-status # 個別に精査しつつ、不要なファイルをunstage git restore --staged src/debug.log git restore --staged tmp/ # 残ったものが本当に意図通りか最終確認 git diff --cached
大量add時の整理はaddの取り消し方法とハンク単位addのgit add -pが強力です。
シナリオ③ 新規ファイルの全内容を確認
# 新規ファイルはdiffでは「全行が+」で表示される git diff --cached src/new_feature.py # ただし大きい新規ファイルではscrollが大変なので、 # indexの中身を丸ごと表示する方が見やすい場合がある git show :src/new_feature.py | less # ファイル数だけ知りたい場合 git diff --cached --stat --name-only | wc -l
シナリオ④ 空白・改行コードの混入チェック
# 空白系を無視した本質的な差分 git diff --cached -w # もし -w で差分が消えるなら「空白だけの変更」しかない # 意図した変更なら問題ないが、エディタ設定で無駄な空白を入れた可能性も # 行末空白・タブ混入のチェック git diff --cached --check # 出力例: # src/auth.py:15: trailing whitespace.
ポイント:--checkは末尾空白・タブ混入などの「スタイル違反」を自動検出します。プロジェクトにlintがなくてもこの一手で最低限の整頓ができます。
バイナリ・大容量ファイル・特殊な差分
画像・音声・PDFなどのバイナリや、改行コード変更のみ、大容量テキストなど、通常のdiffが効きにくい場合の対処法です。
# 通常はバイナリとして扱われ、「Binary files differ」と表示 git diff --cached assets/logo.png # → Binary files a/assets/logo.png and b/assets/logo.png differ # テキスト扱いを強制(壊れた出力になる可能性あり) git diff --cached --text assets/logo.png # バイナリ用にdiff driverを登録する(.gitattributes) # *.png diff=exif # → EXIF情報の差分を表示
# ページャーにlessを使って段階表示(デフォルト) git diff --cached # → lessが起動、qで終了・/で検索 # ページャーなしで一気に流す git --no-pager diff --cached # ファイルに書き出してエディタで確認 git diff --cached > /tmp/staged.patch code /tmp/staged.patch
注意:画像やPDFなどのバイナリをリポジトリに頻繁にコミットしている場合、差分確認が実用的でないうえ、リポジトリサイズが肥大化します。Git LFSの導入や、デザインデータは別ストレージ+URLリンク運用に切り替える検討も有効です。
やってはいけない落とし穴
git diff だけでstaged変更を見ようとする
旧記事でも誤解が広まっていますが、git diffはaddしていない変更を表示します。addしたファイルは「作業ツリーとindexが一致」しているため差分ゼロです。add済みを見たいときは必ず--cachedか--stagedを付けてください。
git status と git diff を同一視する
git statusはファイル単位の状態(Modified/Added/Deleted)を表示するだけで、具体的な行の差分は見せません。どのファイルが変わったかだけ知りたいgit status、中身まで確認したいgit diff --cached、と役割を分けて使ってください。VS Code等のGUIは両方を同じ画面に表示するので混乱しやすいですが、CLIでは別コマンドになります。
コミット直後なのにdiff –cachedが何も出ない
これは正常な動作です。commit後はindexとHEADが一致し、diffは空になります。直前のコミットの内容を見たいならgit show/git log -p -1を使います。commit前にgit diff --cachedで確認する習慣を付けるのがベストです。
–cached と –staged が違うオプションだと思う
完全に同義です。歴史的に--cachedが先にあり、分かりやすさのために--stagedが後から別名として追加されました。どちらを使っても動作は同じなので、チームで統一できれば好みで選んで問題ありません。
行末に書いたメッセージや機密を見落としてcommitする
git diff --cachedを流し読みしていると、「コメントアウトしたAPIキー」「デバッグ用のtodo文字列」「print文」などを見落とします。--checkで空白違反を、-wで本質的な変更だけを、--statで全体の規模感を、と複数の切り口で確認するのが確実です。pre-commit hookで自動検査する仕組みを入れると見落としが減ります。
よくある質問
git diffは「作業ツリー vs index」の比較で、addした瞬間にそのファイルの差分はゼロになります。add済みを見るにはgit diff --cached(または--staged)を使ってください。--stagedを教えるケースが多いですが、既存のドキュメントに合わせて--cachedを使うチームもあります。git diff HEADを使えば「HEAD ↔ 作業ツリー」の差分、つまりadd済みも未addも合わせた全変更が見られます。git diff --cachedでは「全行が+」として表示されます。全体像が見づらい場合はgit show :<file>でindex上のファイル内容をそのまま表示すると読みやすいです。git config --global color.ui autoで自動色付けが有効になります。特定コマンドだけ色を付けたい場合はgit diff --cached --colorで強制的にカラー出力できます。git diff --cachedと同じ情報を見ています。.gitattributesでバイナリ用のdiff driverを定義するか、画像ならGitLFS+各種ビューア、PDFなら専用diffツールを使うのが現実的です。関連記事
- 【Git】addの取り消し方法 — staged変更を戻す方法
- git diff でファイル指定する方法 — 特定ファイルに絞ったdiff操作
- Gitでコミット間の差分を比較する方法 — コミット同士のdiff
- 【Git】ブランチ間の差分を比較する方法 — ブランチ同士のdiff
- 【Git】管理からファイルを外す方法 — addしすぎた際の整理
- 【Git】コミットの取り消し方 — commitしてしまった後の対処
- 【Git】よく使うgitコマンドまとめ — 日常操作の早見表
まとめ
- 素の
git diffは未addの変更を見せるだけ。add済みには--cached/--stagedが必須 - 3種類のdiffビューを使い分け:
git diff/--cached/HEAD - 俯瞰には
--stat・--name-status、精読には通常diff - ワード単位は
--word-diff、空白除外は-w、スタイル検査は--check - indexの中身を丸ごと見たいときは
git show :<file> - GUI/IDEでの視覚確認も併用すると見落としが減る
- commit前に
git diff --cachedで最終確認する習慣がレビュー品質を上げる
「addしたファイルの変更を確認する」はGitの3層構造を理解すれば迷わないテーマです。addは作業ツリーからindexへ変更を写す操作、git diff --cachedはそのindexとHEADの差分を見せる——この関係を押さえれば、自信を持ってcommitへ進めます。日々の開発で「commitする前に必ずdiff –cachedで見る」ルーチンを定着させ、きれいで読みやすい履歴を積み重ねていきましょう。

