【Git】git statusで変更ファイルの中身・差分を確認する方法

GitGit [ギット]ソースコードの変更履歴を管理する分散型バージョン管理システムで作業中、git statusコマンドを実行して変更されたファイルの一覧は確認できるものの、「具体的にどこをどう変更したんだっけ？」と、ファイルの中身まで把握できずに困った経験はありませんか？特に複数のファイルを修正している場合や、しばらく作業から離れていた場合、どの変更をステージングし、どの変更をコミットするべきか判断に迷うこともあるでしょう。

この記事では、Gitの基本コマンドであるgit statusと、変更内容の差分を表示するgit diffコマンドを組み合わせることで、ワークツリーやステージングエリアの変更内容をスマートに、そして効率的に確認する方法を解説します。この記事を読めば、あなたのGitワークフローがよりスムーズになり、自信を持ってコミットできるようになるでしょう。

確認した環境

この記事は以下の環境で動作確認を行っています。

OSOS [オーエス]Operating System。基本ソフトウェア: UbuntuUbuntu [ウブントゥ]人気のLinuxディストリビューション 22.04 LTS
Git: 2.34.1

`git status`だけでは分からない変更内容を把握する重要性

Gitを使った開発では、コードの変更履歴を正確に管理することが不可欠です。git statusは現在のリポジトリの状態を把握するための非常に重要なコマンドですが、これだけでは変更されたファイルの中身までは分かりません。変更内容を正確に把握することは、以下のような点で重要です。

意図しない変更の発見: 誤って追加・削除してしまったコードや、デバッグ用のコードが残っていないかを確認できます。
コミットメッセージの精度向上: 変更内容を理解していれば、より具体的で意味のあるコミットメッセージを作成でき、後から履歴を追う際に役立ちます。
レビューの効率化: 他のメンバーがレビューする際にも、変更者が意図を正確に伝えやすくなります。
コンフリクトの回避・解決: 変更内容を把握していれば、マージ時のコンフリクトを未然に防いだり、発生した場合にスムーズに解決したりできます。

`git status`で確認できる情報の基本おさらい

まずは、git statusコマンドがどのような情報を提供してくれるのか、基本的なおさらいをしましょう。

1
git status

このコマンドを実行すると、通常以下のような情報が表示されます。

1
On branch main
2
Your branch is up to date with 'origin/main'.
3

4
Changes to be committed:
5
  (use "git restore --staged <file>..." to unstage)
6
        modified:   src/index.js
7

8
Changes not staged for commit:
9
  (use "git add <file>..." to update what will be committed)
10
  (use "git restore <file>..." to discard changes in working directory)
11
        modified:   README.md
12

13
Untracked files:
14
  (use "git add <file>..." to include in what will be committed)
15
        new_feature.txt

On branch main: 現在作業しているブランチ名が表示されます。
Your branch is up to date with 'origin/main'.: リモート追跡ブランチ（upstream）が設定されている場合、ローカルブランチとローカルに記録されているリモート追跡ブランチとの比較結果が表示されます。なお、リモートリポジトリの最新状態を反映するには、事前にgit fetchを実行する必要があります。
Changes to be committed:: ステージングエリアに追加され、次のコミットに含まれる変更です。この例では src/index.js が変更されています。
Changes not staged for commit:: ワークツリー（作業ディレクトリ）で変更されたものの、まだステージングエリアに追加されていない変更です。この例では README.md が変更されています。
Untracked files:: Gitの追跡対象になっていないファイルです。新しく作成したファイルのほか、git rm --cached などで追跡対象から外されたファイルなども該当します（この例では new_feature.txt）。

git statusはデフォルトではファイルの「状態」のみを教えてくれますが、具体的に「何がどう変わったのか」までは表示されません。

変更されたファイルの中身（差分）まで一目で見る方法

git statusの実行時に変更内容（差分）までまとめて確認したい場合は、-v（または --verbose）オプションを指定する方法があります。

1
# ステージング済みの差分もあわせて表示する
2
git status -v
3

4
# ステージング済み・未ステージ両方の差分をすべて表示する
5
git status -vv

git status -v: 通常のステータス表示の下に、ステージングエリアに追加された変更の差分（後述する git diff --cached 相当）を表示します。
git status -vv: -v を2つ重ねると、ステージング済みの差分に加えて、まだステージングしていないワークツリーの変更の差分（git diff 相当）も一括で表示します。

なお、git status -v / -vv で差分が表示されるのは、Gitが追跡しているファイルの変更内容です。Untracked files についてはファイル名は表示されますが、ファイルの中身は差分として表示されません。

手軽に全体の差分をざっと眺めたいときには git status -v / -vv が便利ですが、変更ファイルが多い場合や、ステージング前後・特定のファイルだけを切り分けて確認したい場合には、差分表示専用の git diff コマンドを組み合わせるのが効率的です。ここからは、git diff を使った実践的な確認方法を詳しく見ていきましょう。

ステージング前後の差分を効率よく確認するコマンド

Gitのワークフローでは、変更をステージングする前と後で、それぞれ異なる差分を確認することが重要です。これにより、意図しない変更がコミットされるのを防ぎます。

`git diff`でワークツリーとステージングエリアの差分を見る

最も基本的なgit diffコマンドは、ワークツリー（作業ディレクトリ）の変更と、ステージングエリアの変更との差分を表示します。これは、まだgit addしていない変更の内容を確認したい場合に利用します。

1
git diff

例えば、README.mdファイルを修正したが、まだgit add README.mdを実行していない状態でこのコマンドを実行すると、以下のような出力が得られます。

1
diff --git a/README.md b/README.md
2
index 724a87c..1d6704a 100644
3
--- a/README.md
4
+++ b/README.md
5
@@ -1,3 +1,4 @@
6
 # My Awesome Project
7

8
 This is a sample project.
9
+A new line has been added here.

出力の読み方:

diff --git a/README.md b/README.md: aとbは比較対象のファイルを示します。
index 724a87c..1d6704a 100644: Git内部のオブジェクトIDとファイルモードを示します。
--- a/README.md: 比較元のファイル（ステージングエリアに記録されている変更前の状態）を示します。
+++ b/README.md: 比較先のファイル（ワークツリーの現在の状態）を示します。
@@ -1,3 +1,4 @@: 差分が表示されている行の位置と行数を示します。-1,3は「比較元の1行目から始まる3行分」、+1,4は「比較先の1行目から始まる4行分」を表します。
行の先頭の記号:
- (スペース): 変更がない行
- +: 新しく追加された行
- -: 削除された行

このコマンドは、あなたが作業ディレクトリで行った変更が、ステージングエリアにある内容とどのように異なるかを示します。これにより、「この変更をgit addして良いか？」を判断できます。

なお、git diff で表示されるのはGitが追跡しているファイルの差分のみであり、Untracked files（未追跡ファイル）の内容は表示されません。新規作成したファイルの差分を確認したい場合は、git add -N <ファイル名>（--intent-to-add）でインデックスに「追加予定（Intent-to-add）」として登録してから git diff を実行する方法があります。ただし、git add -N は通常のステージングとは異なり、ファイルの内容そのものをインデックスに登録する操作ではありません。通常の git commit で新規ファイルの内容をコミット対象に含める場合は、改めて git add <ファイル名> を実行してください。

`--cached`オプションでコミット前の差分を確認する

git addコマンドで変更をステージングエリアに追加した後、実際にコミットする前にその内容を最終確認したい場合があります。このようなときに使用するのがgit diff --cached（またはgit diff --staged）コマンドです。

このコマンドは、ステージングエリアの内容と、最新のコミット（HEAD）との差分を表示します。

1
git diff --cached
2
# または
3
git diff --staged

例えば、src/index.jsファイルを修正し、git add src/index.jsを実行した後にこのコマンドを実行すると、以下のような出力が得られます。

1
diff --git a/src/index.js b/src/index.js
2
index f123abc..d456def 100644
3
--- a/src/index.js
4
+++ b/src/index.js
5
@@ -1,6 +1,7 @@
6
 console.log("Hello, Git!");
7

8
 function greet(name) {
9
-  console.log(`Hello, ${name}!`);
10
+  console.log(`Greetings, ${name}!`); // Changed greeting message
11
 }
12
+
13
 greet("World");

この出力は、あなたがステージングエリアに追加した変更が、前回のコミットからどのように変わったのかを示します。これにより、「この内容でコミットして良いか？」を最終的に判断できます。意図しない変更が含まれていれば、git restore --staged <ファイル名>でステージングを解除し、再度修正することができます。

補足：`git diff HEAD`でステージング前後をまとめて確認する

ステージング済みの変更と未ステージの変更を区別せず、最新のコミット（HEAD）と現在のワークツリーとの差分をまとめて確認したい場合は、git diff HEAD を使用します（※この場合も Untracked files の内容は表示されません）。

1
git diff HEAD

ここまで紹介した3つの git diff コマンドの比較対象を整理すると、以下のようになります。

コマンド	比較対象	主な用途
`git diff`	インデックス（ステージング） ↔ ワークツリー	`git add` する前の未ステージ変更を確認する
`git diff --cached` (`--staged`)	`HEAD`（最新コミット） ↔ インデックス	`git commit` する前のステージング済み変更を確認する
`git diff HEAD`	`HEAD`（最新コミット） ↔ ワークツリー	ステージング前後を問わず、追跡対象ファイルの最新コミットからの変更を確認する

特定のファイルだけピンポイントで変更内容を確認するコツ

プロジェクトが大きくなると、一度に複数のファイルを変更することがよくあります。その中で、特定のファイルだけに着目して変更内容を確認したい場合もあるでしょう。git diffコマンドにファイル名を指定することで、これを実現できます。

1
# ワークツリーとステージングエリア間の特定のファイルの差分
2
git diff <ファイル名>
3

4
# ステージングエリアと最新コミット間の特定のファイルの差分
5
git diff --cached <ファイル名>

例えば、README.mdの変更だけを確認したい場合は、以下のように実行します。

1
git diff README.md

ステージング済みのsrc/index.jsの変更だけを確認したい場合は、以下のように実行します。

1
git diff --cached src/index.js

複数のファイルを指定することも可能です。

1
git diff file1.txt file2.txt
2
git diff --cached file3.js file4.css

このテクニックは、特に大規模な変更セットの中から特定の変更をレビューしたい場合や、特定のファイルに問題がないかを確認したい場合に非常に役立ちます。

実務で役立つ！`git status`と`diff`の組み合わせテクニック

実際の開発現場では、git statusとgit diffを組み合わせて使うことで、より効率的なワークフローを構築できます。

1. 変更の全体像を把握し、個別の差分を確認する

git statusで全体像を把握: まずgit statusを実行して、どのファイルが変更され、どの状態にあるか（Untracked, Not Staged, Staged）を一覧で確認します。
Terminal window
```
1
git status
```
git diffで未ステージの変更を確認: Changes not staged for commitセクションに表示されたファイルについて、git diff <ファイル名>を実行して、ワークツリーでの変更内容を確認します。これにより、変更をステージングして良いか判断します。
Terminal window
```
1
git diff README.md
2
git diff src/utils.js
```
git addで変更をステージング: 確認した変更が意図通りであれば、git add <ファイル名>でステージングします。
Terminal window
```
1
git add README.md
```
git diff --cachedでステージング後の最終確認: git addした後に、git diff --cached <ファイル名>を実行して、ステージングエリアの内容がコミットされる内容として適切か最終確認します。
Terminal window
```
1
git diff --cached README.md
```
または、ステージングエリア全体の変更を確認するために、ファイル名を指定せずにgit diff --cachedを実行します。
Terminal window
```
1
git diff --cached
```

このフローを繰り返すことで、意図しない変更がコミットされるリスクを最小限に抑えられます。

2. `git status -s` (ショートフォーマット) との組み合わせ

git status -s (または --short) は、git statusの出力を簡潔な形式で表示します。これは、多数のファイルが変更されている場合に、一覧性を高めるのに便利です。

1
git status -s

出力例:

1
 M README.md
2
M  src/index.js
3
?? new_feature.txt

先頭の2文字のステータスコード（XY）は、1文字目（X：左列）がステージングエリアの状態、2文字目（Y：右列）がワークツリーの状態を表しています。空白の位置によって意味が異なるため、以下の表とあわせて確認すると分かりやすくなります（␣ は半角スペースを表します）。

表示（1文字目・2文字目）	状態の意味
`␣M`（1文字目が空白、2文字目が`M`）	ワークツリーで変更あり（未ステージ）
`M␣`（1文字目が`M`、2文字目が空白）	ステージング済み（その後のワークツリー変更なし）
`MM`	ステージング後にワークツリーでもさらに変更あり
`AM`	新規ファイルをステージングした後、さらにワークツリーで変更あり
`??`	Untracked files（Gitの追跡対象になっていないファイル）

上記の出力例に当てはめると、それぞれのファイルは以下の状態であることが一目で分かります。

M README.md: 1文字目が空白、2文字目がMのため、ワークツリーで変更された未ステージのファイルです。
M src/index.js: 1文字目がM、2文字目が空白のため、変更がステージング済みで、その後ワークツリーでは変更されていないファイルです。
?? new_feature.txt: Gitの追跡対象になっていない（Untracked）ファイルです。

このショートフォーマットで変更されたファイルと状態（未ステージかステージング済みか）を特定し、それに応じたgit diffコマンドを実行することで、効率的に差分を確認できます。

1
# 未ステージの変更を確認
2
git diff README.md
3

4
# ステージング済みの変更を確認
5
git diff --cached src/index.js

3. 変更を破棄する前の最終確認

もし、ワークツリーの変更を破棄したい場合（例: git restore <ファイル名>やgit checkout -- <ファイル名>を実行する前）、本当にその変更を捨ててしまって良いか不安になることがあります。そんな時もgit diffが役立ちます。

1
# ワークツリーの変更を破棄する前に内容を確認
2
git diff <ファイル名>

このコマンドで変更内容を確認し、問題ないことを確認してからgit restore <ファイル名>を実行すれば、誤って必要な変更を破棄してしまうリスクを減らせます。

トラブルシューティング: `git diff`で何も表示されない場合

変更がステージングされている可能性: git diffはワークツリーとステージングエリアの差分を表示します。もし変更がすでにgit addされている場合は、git diff --cached（またはステージング前後をまとめて確認できるgit diff HEAD）で確認してください。
Untracked files（未追跡ファイル）である可能性: 新規作成したばかりのファイルなど、Gitの追跡対象になっていないファイルはgit diffでは表示されません。必要に応じてgit add -N <ファイル名>を実行してからgit diffで確認してください。
変更がコミットされている可能性: 変更がすでにgit commitされている場合、git diffもgit diff --cachedも何も表示しません。その場合は、git logでコミット履歴を確認するか、git show <コミットハッシュ>で特定のコミットの変更内容を確認します。
ファイル名が間違っている可能性: 指定したファイル名が間違っていると、差分は表示されません。git statusで正確なファイル名を確認してください。

まとめ

この記事では、git statusとgit diffを組み合わせて、Gitリポジトリの変更内容を効率的に確認する方法を解説しました。

git statusは、ファイルの「状態」（Untracked, Not Staged, Staged）を把握するのに役立ちます。-v（ステージング済みの差分表示）や-vv（未ステージを含む全差分表示）オプションを使えば、ステータスと同時に差分を確認することも可能です。
git diffは、ワークツリーとステージングエリア間の差分を表示し、まだgit addしていない変更内容を確認する際に使用します。
git diff --cachedは、ステージングエリアと最新コミット間の差分を表示し、コミット前にステージング済みの変更内容を最終確認する際に使用します（ステージング前後をまとめて最新コミットと比較したい場合はgit diff HEADが便利です）。
git diff <ファイル名>のようにファイル名を指定することで、特定のファイルのみの差分をピンポイントで確認できます。
git status -s（ショートフォーマット）とgit diffを組み合わせることで、多数の変更がある場合でも効率的に差分を確認し、コミット準備を進めることができます。
変更を破棄する前にgit diffで最終確認を行うことで、意図しないデータ損失を防ぐことが可能です。

これらのコマンドとテクニックを習得することで、あなたのGitワークフローはよりスムーズになり、自信を持って変更を管理できるようになるでしょう。

以上で本記事の解説を終わります。
よいITライフを！

この記事を書いた人

Z (ITナレッジライフ)

現役のITエンジニア。Linux、プログラミング、IT用語など、日々の業務で得た「痒いところに手が届く」技術情報を発信しています。

プロフィールと編集ポリシーを見る →

Gitユーザにお勧めの本 ↗

初心者向け

いちばんやさしいGit&GitHubの教本第3版人気講師が教えるバージョン管理＆共有入門「いちばんやさしい教本」シリーズ

難易度

実用性

読みやすさ

こんな人におすすめ： Gitをこれから使い始める人、挫折した経験がある人

とにかく挫折しない丁寧な解説。チーム開発での基本的な流れを確実にマスターできます。

Amazon 🔴 楽天

お役立ちツール

ITニュース最新の技術ニュースをチェック

技術本書評/レビュープロ厳選のITエンジニア向け技術書

ポモドーロタイマー（Web）テレワークや勉強の集中に

【Git】git statusで変更ファイルの中身・差分を確認する方法

Gitユーザにお勧めの本 ↗

`git status`だけでは分からない変更内容を把握する重要性

`git status`で確認できる情報の基本おさらい

変更されたファイルの中身（差分）まで一目で見る方法

ステージング前後の差分を効率よく確認するコマンド

`git diff`でワークツリーとステージングエリアの差分を見る

`--cached`オプションでコミット前の差分を確認する

補足：`git diff HEAD`でステージング前後をまとめて確認する

特定のファイルだけピンポイントで変更内容を確認するコツ

実務で役立つ！`git status`と`diff`の組み合わせテクニック

1. 変更の全体像を把握し、個別の差分を確認する

2. `git status -s` (ショートフォーマット) との組み合わせ

3. 変更を破棄する前の最終確認

トラブルシューティング: `git diff`で何も表示されない場合

まとめ

Z (ITナレッジライフ)

Gitユーザにお勧めの本 ↗

人気記事

VSCodeでソースコードのステップ数をカウント・集計する

VSCodeの「VS Code Counter」プラグインを使用すると、簡単にソースコードのステップ数をカウント・集計できます。サマリーの結果に加えて、言語ごと、ディレクトリごとの集計結果が出力(CSV,JSON,md等)されます。

ディレクトリ配下の権限・所有者を再帰的に変更する【Linux】

Linuxでディレクトリ配下のディレクトリ・ファイルの権限や所有者を再帰的に変更する場合は、chmodおよびchownコマンドに-Rオプションを指定します。

【WinMerge】プラグインでExcelファイルを比較する方法

WinMergeでPDFを比較する方法

WinMergeとApache PDFBoxプラグインを使って、PDFファイルの差分を確認する方法を解説します。プラグイン導入手順、実際の比較手順までを丁寧に紹介。PDFのテキスト比較を効率化したい方におすすめの記事です。

【Linux】viewコマンドの使い方

お役立ちツール

【Git】git rmの取り消し方法｜誤削除ファイルを復元する手順

【Git】git fetchとpullの違いは？仕組みと安全な使い分け

git configの変更・確認方法！グローバルとローカルの使い分け

git restoreの使い方！ファイルの変更破棄・git addの取り消し方法

Gitの「git restore」コマンドの使い方を徹底解説。ファイルの変更破棄やgit addの取り消し（ステージング解除）など、作業ツリーとインデックス間の復元を図解で分かりやすく紹介します。従来のgit checkoutとの違いも解説。

【Git】git rebaseとmergeの違い・使い分けを徹底解説

Gitユーザにお勧めの本 ↗

git statusだけでは分からない変更内容を把握する重要性

git statusで確認できる情報の基本おさらい

変更されたファイルの中身（差分）まで一目で見る方法

ステージング前後の差分を効率よく確認するコマンド

git diffでワークツリーとステージングエリアの差分を見る

--cachedオプションでコミット前の差分を確認する

補足：git diff HEADでステージング前後をまとめて確認する

特定のファイルだけピンポイントで変更内容を確認するコツ

実務で役立つ！git statusとdiffの組み合わせテクニック

1. 変更の全体像を把握し、個別の差分を確認する

2. git status -s (ショートフォーマット) との組み合わせ

3. 変更を破棄する前の最終確認

トラブルシューティング: git diffで何も表示されない場合

まとめ

Z (ITナレッジライフ)

Gitユーザにお勧めの本 ↗

人気記事

VSCodeでソースコードのステップ数をカウント・集計する

VSCodeの「VS Code Counter」プラグインを使用すると、簡単にソースコードのステップ数をカウント・集計できます。サマリーの結果に加えて、言語ごと、ディレクトリごとの集計結果が出力(CSV,JSON,md等)されます。

ディレクトリ配下の権限・所有者を再帰的に変更する【Linux】

Linuxでディレクトリ配下のディレクトリ・ファイルの権限や所有者を再帰的に変更する場合は、chmodおよびchownコマンドに-Rオプションを指定します。

【WinMerge】プラグインでExcelファイルを比較する方法

WinMergeでPDFを比較する方法

WinMergeとApache PDFBoxプラグインを使って、PDFファイルの差分を確認する方法を解説します。プラグイン導入手順、実際の比較手順までを丁寧に紹介。PDFのテキスト比較を効率化したい方におすすめの記事です。

【Linux】viewコマンドの使い方

お役立ちツール

`git status`だけでは分からない変更内容を把握する重要性

`git status`で確認できる情報の基本おさらい

`git diff`でワークツリーとステージングエリアの差分を見る

`--cached`オプションでコミット前の差分を確認する

補足：`git diff HEAD`でステージング前後をまとめて確認する

実務で役立つ！`git status`と`diff`の組み合わせテクニック

2. `git status -s` (ショートフォーマット) との組み合わせ

トラブルシューティング: `git diff`で何も表示されない場合