Fulfledge

commit 履歴と差分の確認

INPUT · スライド

履歴と差分の確認（log / show / diff / blame）

01 / 09

「このコード、いつ・なぜこうなった？」を調べる

チーム開発や過去のプロジェクトで最も頻繁に遭遇する疑問は次の問いです。

> 「この行のコードは、いつ・誰が・どういう意図で書いたのだろう？」

自分が数ヶ月前に書いたコードでも経緯を忘れることは日常茶飯事です。commit 履歴を丁寧に積み重ねてきた最大の目的は、まさにこの問いに正確に答えるためです。

この章で学ぶ調査系コマンドは、リポジトリの状態を一切変更しない安全なコマンドです。恐れずに何度でも実行しましょう。

02 / 09

git log — commit 履歴の一覧表示

git log は commit 履歴を時系列（新しい順）に表示するコマンドです。目的に応じて便利なオプションを組み合わせて使います。

  • --oneline … 各 commit を1行（commit hash＋メッセージ）で簡潔に表示
  • -n 3（または -3） … 最新の3件のみを表示
  • --graph … branch の分岐や merge を ASCII アートの graph 線で視覚化
  • --stat … 変更されたファイル名と変更行数の統計を表示

特に git log --oneline --graph は、リポジトリ全体の構造を俯瞰する際の標準的なコマンドです。

$ git log --oneline -34d8b2f1 ボタンの色を変更9f2a1c4 入力フォームを追加3b7e5d1 初期コミット

03 / 09

branch を指定して履歴を閲覧する

git log の引数に branch 名を指定すると、current branch を切り替えることなく他の branch の履歴を直接参照できます。

たとえば git log --oneline fix と入力すれば、現在作業中の branch にいながら fix branch の最新進捗を確認できます。

origin/main などの remote 追跡 branch も同様に指定可能です。

$ git log --oneline fix7c1e4a9 緊急の修正3b7e5d1 初期コミット

04 / 09

git show — 特定 commit の詳細と差分（diff）を表示する

git log が commit の一覧を表示するのに対し、git show は特定の1つの commit の詳細な変更内容（差分）を表示します。

git show HEAD で直前の commit、git show HEAD~2 で3つ前の commit、または git show 4d8b2f1 のように commit hash を直接指定します。

commit message、作成者、日時、そして変更されたファイルの具体的な差分が出力されます。

$ git show HEADcommit 4d8b2f1    ボタンの色を変更diff --git a/style.css b/style.css-button { color: navy; }+button { color: crimson; }

05 / 09

差分（diff）の読み方

Git の diff 出力における記号の意味は以下の通りです。

  • - で始まる行（通常赤字） … 変更前のコード（削除された行）
  • + で始まる行（通常緑字） … 変更後のコード（追加された行）
  • 先頭に記号のない行 … 変更されていない前後のコンテキスト行

Git は「行の編集」を「古い行の削除（-）と新しい行の挿入（+）」の組み合わせとして表現します。

06 / 09

git diff — 領域ごとの差分を比較する

git diff は指定するオプションによって、どの領域同士を比較するかが変化します。

  • git diff … working tree ↔ staging area（まだ git add していない作業差分）
  • git diff --staged … staging area ↔ HEAD commit（git add 済みで、次回 commit 予定の差分）
  • git diff HEAD … working tree ↔ HEAD commit（未 commit の全差分）
  • git diff HEAD~2 HEAD … commit 同士の差分（指定した2つの時点間の全変更）

特に最初の2つの使い分けを理解すると、なぜ Git に「staging area」が存在するのかが明確に理解できます。

07 / 09

commit 直前に必ず git diff --staged で確認する

git diff --staged は、commit を実行する直前の最終セーフティネットとして極めて有用です。

これからリポジトリに永久記録されようとしている差分そのものが表示されます。

  • 不要なデバッグ用の console.log が混入していないか
  • 意図しない一時ファイルや無関係な変更が含まれていないか
  • 仕様通りの変更になっているか

git status が変更されたファイル名を一覧表示するのに対し、git diff --staged は変更された具体的な行を教えてくれます。commit 前の習慣にしましょう。

$ git diff --staged+function add(a, b) {+  return a + b+}+console.log("デバッグ用ログ")

08 / 09

git blame — ファイルの各行を誰がいつ変更したか調べる

git blame <ファイル名> を実行すると、ファイル内の全行について、それぞれが「どの commit で・誰が・いつ」追加・変更されたかを行ごとに表示します。

「この不可解な条件分岐はなぜ存在するのだろう？」と疑問に思ったときに実行します。

行を変更した commit hash が特定できれば、git show <commitHash> で当時の commit message と PR の背景意図を正確に読み解くことができます。

$ git blame app.js3b7e5d1 (Alice 1) const ok = true9f2a1c4 (Bob   2) console.log(ok)

09 / 09

調査してから修正する（実践アプローチ）

この章の演習問題は、すべて実務に即した形式で出題されます。

問題文には「どの commit が不具合の原因か」は明示されていません。

1. git log --oneline や git blame であたりをつける
2. git show で commit 差分を詳細確認して原因を特定する
3. 特定した原因に応じて git revert や git restore で適切に修正する

調査用コマンドはリポジトリを一切改変しないため、納得がいくまで何度でも実行して調査してください。