【Git】addしたファイルの変更を確認する方法|diff –cached/–stagedとstat・word-diff活用の完全ガイド

【Git】addしたファイルの変更を確認する方法 Git

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--stagedadd済みの変更だけを確認する方法
  • ファイル一覧だけ・統計だけ・ワード単位などの表示バリエーション
  • git show :FILEでindexのファイル内容を直接確認する方法
  • VS Code/IntelliJ/SourceTree/git difftoolでのGUI確認
  • バイナリ・大容量ファイル・改行コード変更など特殊ケースの見方
  • コミット前レビューの具体的ワークフロー
スポンサーリンク

まず押さえる:diffが比較する3つの場所

Gitでは作業ツリー/index/HEADという3つの状態があり、git diffはオプション次第で比較対象が変わります。「addしたファイルの変更を見たい」には、適切な比較対象を選ぶ必要があります。

コマンド 比較する場所 意味
git diff 作業ツリー ↔ index 未addの変更(unstaged)
git diff --cached
git diff --staged
index ↔ HEAD add済みの変更(staged)
git diff HEAD 作業ツリー ↔ HEAD 未add+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済み変更の基本表示
# 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出力の構造
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で有効化

表示バリエーション:用途別の見せ方

ファイル一覧だけ確認したい

–name-only / –name-status
# 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

規模感だけ把握したい(統計)

–stat / –shortstat
# ファイル別の変更行数を表示
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

ワード単位で差分を見たい

–word-diff で単語単位
# 単語単位の差分(日本語でもスペース区切りなら動く)
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のファイル内容を表示
# 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で比較する

git difftool でGUI差分ビューア
# デフォルトの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 --statgit 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が強力です。

シナリオ③ 新規ファイルの全内容を確認

新規addファイルの中身を見る
# 新規ファイルは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 diffaddしていない変更を表示します。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 showgit log -p -1を使います。commit前にgit diff --cachedで確認する習慣を付けるのがベストです。

–cached と –staged が違うオプションだと思う

完全に同義です。歴史的に--cachedが先にあり、分かりやすさのために--stagedが後から別名として追加されました。どちらを使っても動作は同じなので、チームで統一できれば好みで選んで問題ありません。

行末に書いたメッセージや機密を見落としてcommitする

git diff --cachedを流し読みしていると、「コメントアウトしたAPIキー」「デバッグ用のtodo文字列」「print文」などを見落とします。--checkで空白違反を、-wで本質的な変更だけを、--statで全体の規模感を、と複数の切り口で確認するのが確実です。pre-commit hookで自動検査する仕組みを入れると見落としが減ります。

よくある質問

Qaddしたのにgit diffで何も出ない
A正常です。git diffは「作業ツリー vs index」の比較で、addした瞬間にそのファイルの差分はゼロになります。add済みを見るにはgit diff --cached(または--staged)を使ってください。
Q–cached と –staged は何が違う?
A完全に同義のオプション名です。好みで使い分けてOKです。新規メンバーには「staged」のほうが直感的なので--stagedを教えるケースが多いですが、既存のドキュメントに合わせて--cachedを使うチームもあります。
Qaddしたファイルとしていないファイル両方を一気に見たい
Agit diff HEADを使えば「HEAD ↔ 作業ツリー」の差分、つまりadd済みも未addも合わせた全変更が見られます。
Q新規ファイルの中身をstaged状態で見るには?
Agit diff --cachedでは「全行が+」として表示されます。全体像が見づらい場合はgit show :<file>でindex上のファイル内容をそのまま表示すると読みやすいです。
Q色分けされないので見づらい
Agit config --global color.ui autoで自動色付けが有効になります。特定コマンドだけ色を付けたい場合はgit diff --cached --colorで強制的にカラー出力できます。
QVS Codeでstaged差分を確認するには?
AサイドバーのSource Control(Ctrl+Shift+G)を開き、「STAGED CHANGES」の配下にあるファイルをクリックするとdiffビューに表示されます。内部的にはgit diff --cachedと同じ情報を見ています。
Qバイナリファイルの差分を表示させたい
Aデフォルトでは「Binary files differ」としか出ません。.gitattributesでバイナリ用のdiff driverを定義するか、画像ならGitLFS+各種ビューア、PDFなら専用diffツールを使うのが現実的です。

関連記事

まとめ

  • 素のgit diffは未addの変更を見せるだけ。add済みには--cached--stagedが必須
  • 3種類のdiffビューを使い分け:git diff--cachedHEAD
  • 俯瞰には--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で見る」ルーチンを定着させ、きれいで読みやすい履歴を積み重ねていきましょう。