記事の説明を修正したつもりなのに、関係のない段落まで消してしまった。READMEに追記した内容を、コミットする前にもう一度確かめたい。そんなときに役立つのが、diff、つまり差分です。
差分は、2つの状態を比べて、変わった部分を示します。Gitでは、編集中の内容、ステージングした内容、コミット済みの内容などを比べられます。
この記事では、READMEの修正を例に、差分の読み方と確認の手順を学びます。掲載する文章と出力は説明用の例で、Git公式資料に基づく入門記事です。
1. 差分は「変わった部分」を見るためのもの
差分を読むときは、最初に「何と何を比べているか」を確認します。
たとえば、READMEの保存場所の説明を、次のように修正したとします。
| 状態 | READMEの文章 |
|---|---|
| 修正前 | 原稿はメモフォルダーに保存します。 |
| 修正後 | 原稿はarticlesフォルダーに保存します。 |
差分では、修正前の行を取り除き、修正後の行を追加した形で表示できます。ファイル全体を読み直すときよりも、今回の変更に注目しやすくなります。
Gitのdiffには、作業中のファイルを比較する使い方と、コミット同士を比較する使い方があります。比較対象を指定することが、差分確認の出発点です。Git公式：git diff
差分を見ただけで、文章やプログラムが正しいと保証されるわけではありません。変更の意図を確認し、必要に応じて前後の文章を読んだり、動作を確かめたりします。
2. statusで一覧を見て、diffで中身を見る
git statusとgit diffは、確認する内容が違います。
| コマンド | 確認すること | 読むときの問い |
|---|---|---|
git status |
変更されたファイルや、ステージングの状態 | どのファイルに変更があるか？ |
git diff |
ステージング前の変更の中身 | どの行をどう変えたか？ |
git diff --staged |
ステージングした変更の中身 | 次のコミットに何を含めるか？ |
まず一覧で対象をつかみ、それから行ごとの変更を読むと整理しやすくなります。git statusは、作業ツリーとステージングエリアの状態に加え、未追跡ファイルも表示します。Git公式：git status
新しく作った未追跡ファイルは、通常のgit diffには内容が表示されません。ステージングすると、追加予定のファイルとしてgit diff --stagedで確認できます。「diffに出ていないから、ファイルを作っていない」と判断しないようにしましょう。Git公式：変更の記録
3. マイナス・プラス・行番号を読む
READMEの修正を、差分として表すと次のようになります。これは、読み方を説明するための出力例です。
diff --git a/README.md b/README.md
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
# 記事メモ
-原稿はメモフォルダーに保存します。
+原稿はarticlesフォルダーに保存します。
画像はimagesフォルダーに保存します。読みどころを分けてみましょう。
| 表示 | 意味 |
|---|---|
diff --git a/README.md b/README.md |
比較するファイルを示す見出し |
--- a/README.md |
比較の前側のファイル |
+++ b/README.md |
比較の後側のファイル |
@@ -1,3 +1,3 @@ |
前側は1行目から3行、後側も1行目から3行を示す範囲情報 |
本文の先頭にある- |
前側にあり、後側では取り除かれた行 |
本文の先頭にある+ |
後側に追加された行 |
| 本文の先頭にある空白 | 周囲の文脈を示す、変わっていない行 |
この例では「メモフォルダー」という説明を取り除き、「articlesフォルダー」という説明を追加しています。行の置き換えも、削除と追加の組み合わせで表されます。
a/とb/は比較する側を示す接頭辞で、実際にその名前のフォルダーを作ったという意味ではありません。また、---と+++のファイル見出しは、本文の削除・追加の行と区別して読みます。Git公式：差分の形式
ツールによって色や表示方法は異なります。色だけに頼らず、記号と比較対象を見て判断しましょう。
4. 比較する場所を変えると、見える差分も変わる
前回のコミット・ステージングの記事では、作業ツリー、ステージングエリア、コミット済みの履歴を分けて考えました。diffでも、この区別が大切です。
| コマンド | 比較の基準と対象 |
|---|---|
git diff |
ステージングエリアを基準に、作業ツリーを見る |
git diff --staged |
HEADのコミットを基準に、ステージングエリアを見る |
git diff HEAD |
HEADのコミットを基準に、作業ツリーを見る |
HEADは現在の位置を示し、通常のブランチ上での作業では、そのブランチの先端コミットに対応します。上の表は、HEADのコミットが存在する通常のリポジトリを想定しています。
--stagedは--cachedと同じ意味です。git diff HEADは、ステージングの前後をまとめて、現在のファイルがHEADからどう変わったかを見るときに使えます。ただし、未追跡ファイルは含まれません。Git公式：git diffの比較対象
「差分を見る」という同じ言葉でも、何を基準にするかで結果が変わります。コマンドを実行する前に、見たいのは編集中の変更か、コミット予定の変更かを決めましょう。
→ステージングエリア
→作業ツリー
→作業ツリー
5. READMEの修正を確認してからコミットする
ここからは、コミット済みのREADMEがある練習用リポジトリを想定します。保存場所の説明を修正し、ファイルを保存したところから始めます。
手順1：変更されたファイルを確認する
git statusREADME以外にも変更があるなら、それが今回の作業に関係するかを確認します。
手順2：ステージング前の差分を読む
git diff -- README.md対象をREADMEに絞って、追加した説明、取り除いた説明、周囲の文章を読みます。--は、オプションやコミットの指定と、ファイルの指定を区切るために使います。
手順3：変更を選んで、記録予定を確認する
git add README.md
git diff --stagedここで見るのは、次のコミットに含まれる変更です。ほかのファイルがすでにステージングされていれば、それらも表示されるため、全体を確認します。
手順4：コミットし、残った変更を確認する
git commit -m "READMEの原稿保存先を修正"
git status確認してから記録する、という順番を習慣にすると、意図しない変更に気づきやすくなります。ステージングとコミットの関係は、Git公式の変更記録の説明でも確認できます。Git公式：変更の記録
- コミット済みのREADMEを修正して保存対象をつかむ ↓
- git status：変更されたファイルを確認変更の中身を読む ↓
- git diff — README.md：追加・削除・周囲の文章を読む確認した変更を選ぶ ↓
- git add README.md：変更をステージング次のコミットに含まれる変更を確認 ↓
- git diff –staged：ほかのステージング済みファイルも含めて確認確認してから記録 ↓
- git commit：確認した変更を記録記録後の状態を確認 ↓
- git status：残った変更を確認
6. diffが空でも、変更がないとは限らない
READMEの修正をgit addした後に、普通のgit diffを実行すると、何も表示されない場合があります。この場合は「変更が消えた」のではなく、作業ツリーとステージングエリアが一致している可能性があります。
そこでgit statusとgit diff --stagedを確認すると、コミット予定の変更が残っているかを判断できます。
さらに、ステージングした後でREADMEへ画像の保存先を追記すると、次のように分かれます。これは説明用の例です。
| 確認するコマンド | この例で見える変更 |
|---|---|
git diff --staged |
最初に選んだ、原稿の保存先の修正 |
git diff |
その後に編集した、画像の保存先の追記 |
追記も今回のコミットに含めたいなら、内容を確認して再びステージングします。ファイルを保存することと、次のコミットに含めることは別の操作です。Git公式：ステージング後の編集
何も表示されないときは、「どこを比べた結果が空なのか」を確認するのがポイントです。
→git diffが空の場合：作業ツリーとステージングエリアが一致している可能性
→git statusとgit diff –stagedで記録予定の変更を確認
→ステージング後に画像の保存先を追記する例
→git diff –staged：最初に選んだ原稿の保存先の修正
→git diff：その後に編集した画像の保存先の追記
→追記も今回のコミットに含めたいなら、内容を確認して再びステージング
7. 差分を読むときに確認したいこと
この記事のREADME修正なら、次の順で見直すと判断しやすくなります。
- 比較対象は、編集中の内容か、コミット予定の内容か。
- 変更したファイルは、今回の作業に必要なものか。
- 追加した説明は、実際の保存先と一致しているか。
- 削除した行に、残すべき説明が含まれていないか。
- 周囲の説明と矛盾していないか。
差分だけでは変更の理由はわかりません。理由をコミットメッセージや作業メモに残すと、あとから読む人が判断しやすくなります。
また、画像などのバイナリーファイルは、テキストのような行ごとの表示にならないことがあります。その場合は、変更前後の画像や、ファイルを開いた結果も確認します。差分表示の形式には複数の種類があります。Git公式：差分の形式
worktreeを使っている場合は、どの作業フォルダーでコマンドを実行しているかも確認してください。この確認手順は、前回の記事で分けた作業場所を取り違えないためにも役立ちます。
8. まとめと理解度確認
diffは、2つの状態を比べて、何が変わったかを読むための仕組みです。最初に比較対象を決め、追加と削除の中身を確認しましょう。
コミット前には、git statusで状態をつかみ、git diffで編集中の変更を読み、ステージング後にgit diff --stagedで記録予定を確かめる、という流れが使えます。
自分の言葉で説明してみる
git statusとgit diffは、何を確認する点が違いますか？- 差分本文の先頭にある
-と+は、それぞれ何を示しますか？ - 次のコミットに含める変更を確認するコマンドは何ですか？
- ステージング後、普通の
git diffが空なら、変更は必ず消えていますか？ - 新しく作った未追跡ファイルの内容は、普通の
git diffに表示されますか？
解答例
- statusはファイルやステージングの状態を、diffは比較対象の変更の中身を確認します。
-は前側から取り除かれた行、+は後側へ追加された行です。git diff --stagedです。git diff --cachedも同じ意味です。- 消えたとは限りません。ステージング済みなら、普通のdiffが空でも記録予定の変更が残っている場合があります。
- 通常は表示されません。statusで存在を確認し、ステージング後に
git diff --stagedで追加内容を確認できます。
参考資料
資料確認日：2026年10月11日
記事の説明を修正したつもりなのに、関係のない段落まで消してしまった。READMEに追記した内容を、コミットする前にもう一度確かめたい。そんなときに役立つのが、diff、つまり差分です。
差分は、2つの状態を比べて、変わった部分を示します。Gitでは、編集中の内容、ステージングした内容、コミット済みの内容などを比べられます。
この記事では、READMEの修正を例に、差分の読み方と確認の手順を学びます。掲載する文章と出力は説明用の例で、Git公式資料に基づく入門記事です。
1. 差分は「変わった部分」を見るためのもの
差分を読むときは、最初に「何と何を比べているか」を確認します。
たとえば、READMEの保存場所の説明を、次のように修正したとします。
| 状態 | READMEの文章 |
|---|---|
| 修正前 | 原稿はメモフォルダーに保存します。 |
| 修正後 | 原稿はarticlesフォルダーに保存します。 |
差分では、修正前の行を取り除き、修正後の行を追加した形で表示できます。ファイル全体を読み直すときよりも、今回の変更に注目しやすくなります。
Gitのdiffには、作業中のファイルを比較する使い方と、コミット同士を比較する使い方があります。比較対象を指定することが、差分確認の出発点です。Git公式：git diff
差分を見ただけで、文章やプログラムが正しいと保証されるわけではありません。変更の意図を確認し、必要に応じて前後の文章を読んだり、動作を確かめたりします。
2. statusで一覧を見て、diffで中身を見る
git statusとgit diffは、確認する内容が違います。
| コマンド | 確認すること | 読むときの問い |
|---|---|---|
git status |
変更されたファイルや、ステージングの状態 | どのファイルに変更があるか？ |
git diff |
ステージング前の変更の中身 | どの行をどう変えたか？ |
git diff --staged |
ステージングした変更の中身 | 次のコミットに何を含めるか？ |
まず一覧で対象をつかみ、それから行ごとの変更を読むと整理しやすくなります。git statusは、作業ツリーとステージングエリアの状態に加え、未追跡ファイルも表示します。Git公式：git status
新しく作った未追跡ファイルは、通常のgit diffには内容が表示されません。ステージングすると、追加予定のファイルとしてgit diff --stagedで確認できます。「diffに出ていないから、ファイルを作っていない」と判断しないようにしましょう。Git公式：変更の記録
3. マイナス・プラス・行番号を読む
READMEの修正を、差分として表すと次のようになります。これは、読み方を説明するための出力例です。
diff --git a/README.md b/README.md
--- a/README.md
+++ b/README.md
@@ -1,3 +1,3 @@
# 記事メモ
-原稿はメモフォルダーに保存します。
+原稿はarticlesフォルダーに保存します。
画像はimagesフォルダーに保存します。読みどころを分けてみましょう。
| 表示 | 意味 |
|---|---|
diff --git a/README.md b/README.md |
比較するファイルを示す見出し |
--- a/README.md |
比較の前側のファイル |
+++ b/README.md |
比較の後側のファイル |
@@ -1,3 +1,3 @@ |
前側は1行目から3行、後側も1行目から3行を示す範囲情報 |
本文の先頭にある- |
前側にあり、後側では取り除かれた行 |
本文の先頭にある+ |
後側に追加された行 |
| 本文の先頭にある空白 | 周囲の文脈を示す、変わっていない行 |
この例では「メモフォルダー」という説明を取り除き、「articlesフォルダー」という説明を追加しています。行の置き換えも、削除と追加の組み合わせで表されます。
a/とb/は比較する側を示す接頭辞で、実際にその名前のフォルダーを作ったという意味ではありません。また、---と+++のファイル見出しは、本文の削除・追加の行と区別して読みます。Git公式：差分の形式
ツールによって色や表示方法は異なります。色だけに頼らず、記号と比較対象を見て判断しましょう。
4. 比較する場所を変えると、見える差分も変わる
前回のコミット・ステージングの記事では、作業ツリー、ステージングエリア、コミット済みの履歴を分けて考えました。diffでも、この区別が大切です。
| コマンド | 比較の基準と対象 |
|---|---|
git diff |
ステージングエリアを基準に、作業ツリーを見る |
git diff --staged |
HEADのコミットを基準に、ステージングエリアを見る |
git diff HEAD |
HEADのコミットを基準に、作業ツリーを見る |
HEADは現在の位置を示し、通常のブランチ上での作業では、そのブランチの先端コミットに対応します。上の表は、HEADのコミットが存在する通常のリポジトリを想定しています。
--stagedは--cachedと同じ意味です。git diff HEADは、ステージングの前後をまとめて、現在のファイルがHEADからどう変わったかを見るときに使えます。ただし、未追跡ファイルは含まれません。Git公式：git diffの比較対象
「差分を見る」という同じ言葉でも、何を基準にするかで結果が変わります。コマンドを実行する前に、見たいのは編集中の変更か、コミット予定の変更かを決めましょう。
→ステージングエリア
→作業ツリー
→作業ツリー
5. READMEの修正を確認してからコミットする
ここからは、コミット済みのREADMEがある練習用リポジトリを想定します。保存場所の説明を修正し、ファイルを保存したところから始めます。
手順1：変更されたファイルを確認する
git statusREADME以外にも変更があるなら、それが今回の作業に関係するかを確認します。
手順2：ステージング前の差分を読む
git diff -- README.md対象をREADMEに絞って、追加した説明、取り除いた説明、周囲の文章を読みます。--は、オプションやコミットの指定と、ファイルの指定を区切るために使います。
手順3：変更を選んで、記録予定を確認する
git add README.md
git diff --stagedここで見るのは、次のコミットに含まれる変更です。ほかのファイルがすでにステージングされていれば、それらも表示されるため、全体を確認します。
手順4：コミットし、残った変更を確認する
git commit -m "READMEの原稿保存先を修正"
git status確認してから記録する、という順番を習慣にすると、意図しない変更に気づきやすくなります。ステージングとコミットの関係は、Git公式の変更記録の説明でも確認できます。Git公式：変更の記録
- コミット済みのREADMEを修正して保存対象をつかむ ↓
- git status：変更されたファイルを確認変更の中身を読む ↓
- git diff — README.md：追加・削除・周囲の文章を読む確認した変更を選ぶ ↓
- git add README.md：変更をステージング次のコミットに含まれる変更を確認 ↓
- git diff –staged：ほかのステージング済みファイルも含めて確認確認してから記録 ↓
- git commit：確認した変更を記録記録後の状態を確認 ↓
- git status：残った変更を確認
6. diffが空でも、変更がないとは限らない
READMEの修正をgit addした後に、普通のgit diffを実行すると、何も表示されない場合があります。この場合は「変更が消えた」のではなく、作業ツリーとステージングエリアが一致している可能性があります。
そこでgit statusとgit diff --stagedを確認すると、コミット予定の変更が残っているかを判断できます。
さらに、ステージングした後でREADMEへ画像の保存先を追記すると、次のように分かれます。これは説明用の例です。
| 確認するコマンド | この例で見える変更 |
|---|---|
git diff --staged |
最初に選んだ、原稿の保存先の修正 |
git diff |
その後に編集した、画像の保存先の追記 |
追記も今回のコミットに含めたいなら、内容を確認して再びステージングします。ファイルを保存することと、次のコミットに含めることは別の操作です。Git公式：ステージング後の編集
何も表示されないときは、「どこを比べた結果が空なのか」を確認するのがポイントです。
→git diffが空の場合：作業ツリーとステージングエリアが一致している可能性
→git statusとgit diff –stagedで記録予定の変更を確認
→ステージング後に画像の保存先を追記する例
→git diff –staged：最初に選んだ原稿の保存先の修正
→git diff：その後に編集した画像の保存先の追記
→追記も今回のコミットに含めたいなら、内容を確認して再びステージング
7. 差分を読むときに確認したいこと
この記事のREADME修正なら、次の順で見直すと判断しやすくなります。
- 比較対象は、編集中の内容か、コミット予定の内容か。
- 変更したファイルは、今回の作業に必要なものか。
- 追加した説明は、実際の保存先と一致しているか。
- 削除した行に、残すべき説明が含まれていないか。
- 周囲の説明と矛盾していないか。
差分だけでは変更の理由はわかりません。理由をコミットメッセージや作業メモに残すと、あとから読む人が判断しやすくなります。
また、画像などのバイナリーファイルは、テキストのような行ごとの表示にならないことがあります。その場合は、変更前後の画像や、ファイルを開いた結果も確認します。差分表示の形式には複数の種類があります。Git公式：差分の形式
worktreeを使っている場合は、どの作業フォルダーでコマンドを実行しているかも確認してください。この確認手順は、前回の記事で分けた作業場所を取り違えないためにも役立ちます。
8. まとめと理解度確認
diffは、2つの状態を比べて、何が変わったかを読むための仕組みです。最初に比較対象を決め、追加と削除の中身を確認しましょう。
コミット前には、git statusで状態をつかみ、git diffで編集中の変更を読み、ステージング後にgit diff --stagedで記録予定を確かめる、という流れが使えます。
自分の言葉で説明してみる
git statusとgit diffは、何を確認する点が違いますか？- 差分本文の先頭にある
-と+は、それぞれ何を示しますか？ - 次のコミットに含める変更を確認するコマンドは何ですか？
- ステージング後、普通の
git diffが空なら、変更は必ず消えていますか？ - 新しく作った未追跡ファイルの内容は、普通の
git diffに表示されますか？
解答例
- statusはファイルやステージングの状態を、diffは比較対象の変更の中身を確認します。
-は前側から取り除かれた行、+は後側へ追加された行です。git diff --stagedです。git diff --cachedも同じ意味です。- 消えたとは限りません。ステージング済みなら、普通のdiffが空でも記録予定の変更が残っている場合があります。
- 通常は表示されません。statusで存在を確認し、ステージング後に
git diff --stagedで追加内容を確認できます。
参考資料
資料確認日：2026年10月11日
コメント