System Note
$ cat /proc/ai-disclosure
本記事の構成および論理分析にはAI（人工知能）を使用しています。情報の正確性は、システム管理者（UNIXユーザー）による手動検証済みです。
第４回 | git diff で変更を確認し git log で履歴を見返す | コミット前後に使う確認と振り返りの流れ | UNIX Cafe
Git 入門 | 第４回
変更を記録できるようになったら、次に大切なのは「記録する前に中身を確認する」と「記録した履歴を見返す」という 2 つの習慣です。この 2 つがそろうと、Git を安心して使い続けられるようになります。
今回は git diff と git log をセットで整理します。前者は記録前の確認、後者は記録後の振り返りに使う道具です。
動画で流れを先に見たい方は、UNIX Cafe の YouTube もあわせてどうぞ。記事と同じく、初心者向けのやさしい流れで、ターミナルの最初の一歩を確認できます。
📝 この記事で学べること
git diffで変更の中身を確認する方法git diff --stagedで記録予定の内容を確認する方法- diff の出力の読み方
git logで履歴をたどる方法git log --onelineで見やすく確認する方法- 初心者がつまずきやすいポイントと対処
目次
git diff | 変更の中身を見る道具
まず、前回の続きで memo.txt に何か追記して保存しておきましょう。vi で編集する場合は次のようにします。
vi memo.txt- i で入力モードに入り、テキストを追記します。
- 書き終えたら Esc を押して、
:wqで保存・終了します。 - 変更が保存できたら、以下の手順で確認していきましょう。
git status では「どのファイルが変わったか」は分かりますが、「どの行がどう変わったか」までは分かりません。そこで使うのが git diff です。
| コマンド | 何を見るか |
|---|---|
git status | どのファイルが変わっているか（全体像） |
git diff | 何がどう変わったか（中身） |
まず status で全体を確認し、次に diff で中身を見る。この順番を意識すると、記録前の確認がとても落ち着いてできます。
git diff実行しても何も表示されない場合は、ファイルをまだ編集していないか、すでに git add 済みの可能性があります。add 後の変更を見たいときは git diff --staged を使います。
diff の出力を読む
初めて git diff の出力を見ると、記号が多くて戸惑いやすいです。実際の出力を見ながら、読み方を確認していきましょう。
diff --git a/memo.txt b/memo.txt
index 83db48f..f735c1d 100644
--- a/memo.txt
+++ b/memo.txt
@@ -1,3 +1,4 @@
はじめてのファイル
-確認中
+確認完了
+追記: ログを残した| 表示 | 意味 |
|---|---|
--- a/memo.txt | 変更前のファイル |
+++ b/memo.txt | 変更後のファイル |
@@ -1,3 +1,4 @@ | 変更が起きた行の範囲 |
- で始まる行 | 削除された行（変更前） |
+ で始まる行 | 追加された行（変更後） |
| 何もついていない行 | 変更のない前後の文脈行 |
- と + を見るだけで、何が消えて何が追加されたかを追えます。最初は @@ の行の数字は気にせず、- と + の行だけ読む習慣からはじめると十分です。
git diff –staged | 記録予定の内容を確認する
git diff は add していない変更を見ます。一方、git add 済みの変更、つまり次の commit に含まれる予定の内容を確認したいときは --staged をつけます。
git diff --staged「本当にこの内容を記録してよいか」を commit の直前に確認する最終チェックとして使うと安心です。add したつもりのないファイルが混ざっていないか、意図しない変更が含まれていないかを見てから進める習慣をつけましょう。
git log | 記録した履歴をたどる
git commit で変更を残したあと、その記録をあとから見返せるのが Git の大きな価値のひとつです。git log を使うと、これまでに残してきたコミットを一覧で確認できます。
git log実行すると、次のような出力が表示されます。
commit a1b2c3d4e5f6...
Author: yourname <you@example.com>
Date: Mon May 12 21:00:00 2026 +0900
memo.txt に確認状況を追記
commit 9f8e7d6c5b4a...
Author: yourname <you@example.com>
Date: Sun May 11 20:30:00 2026 +0900
はじめてのメモを追加| 表示 | 意味 |
|---|---|
commit a1b2c3d... | コミット ID（変更を識別する番号） |
Author: | 変更を記録した人の名前とメールアドレス |
Date: | 記録した日時 |
| メッセージ行 | コミット時に書いたメッセージ |
Author: に表示される名前とメールアドレスは、あらかじめ git config で設定した情報が使われます。設定していない場合はシステムのユーザー名が使われることがあります。設定を確認したいときは次のコマンドで確認できます。
git config user.name
git config user.email新しい順に並んでいるので、一番上が最新のコミットです。「いつ何を変えたか」の流れがここで見えてきます。
git log –oneline | まずざっと全体を見る
コミットが増えてくると、git log の出力が長くなって全体を追いにくくなります。そんなときに役立つのが --oneline オプションです。
git log --oneline1 コミットを 1 行で表示してくれるので、全体の流れをざっと確認するのに向いています。
a1b2c3d memo.txt に確認状況を追記
9f8e7d6 はじめてのメモを追加左の短い番号がコミット ID の先頭部分、右がコミットメッセージです。「あの変更はいつ入れたっけ」と確認したいときに、まずこの表示で全体を見渡してから探すと効率よくたどれます。
初心者がつまずきやすいポイント
実際に操作してみると、いくつか「あれ？」となりやすい場面があります。あらかじめ知っておくと慌てずに済みます。
- git diff を実行しても何も表示されない
-
2 つの原因が考えられます。ひとつは、ファイルをまだ編集していない場合。もうひとつは、編集済みのファイルをすでに git add してしまっている場合です。add 後の変更を見たいときは git diff –staged を使います。
- git log の表示が長くて抜け出せない
-
git log はページャー（less）で表示されるため、スクロールしても終わらないように見えることがあります。
qキーを押すと終了できます。最初から短く見たい場合は git log –oneline を使うと扱いやすいです。 - コミットメッセージが「update」だらけで履歴が読めない
-
これは git log を見たときに初めて気づく問題です。「何を変えたか分かるメッセージ」を書く習慣は、記録するときより、あとで見返すときに効いてきます。前回の記事で紹介したメッセージの書き方を参考にしてみてください。
確認と振り返りの流れを整理する
ここまでの内容を、実際の作業の流れに当てはめるとこうなります。
- ファイルを編集する
git diffで何が変わったか確認するgit addで今回残したい変更を選ぶgit diff --stagedで記録予定の内容を最終確認するgit commit -m "メッセージ"で履歴に残すgit log --onelineで記録が積み重なっていることを確認する
この流れが身につくと、「何を記録したのか分からなくなった」「意図しない変更が混ざっていた」といったミスがかなり減ります。
次回は git restore と総まとめを見ていきます
記録する流れが見えてきたら、次は「やり直したいとき」の話です。次回は git restore で未記録の変更を落ち着いて戻す方法と、シリーズ全体の流れを通して整理します。
