技術資料

既存システムを調べていて、「この条件はいつ追加されたのか」「なぜこの処理が必要なのか」などと思ったときは、コードを読むだけでなく、Gitの変更履歴も確認してみましょう。

まずはgit blameで対象行を最後に変更したコミットを見つけ、git showで差分を確認します。さらに前の変更や、既に削除された条件を探したいときは、git logの範囲指定や文字列検索が使えます。

今回は、これらの基本を整理してから、PHPの条件分岐を例に履歴を調べる流れを紹介します。ブランチやcommitの基本は、GitHub入門の記事を参照してください。

履歴から何を知りたいかで、コマンドを選ぶ

調べたいこと	使うコマンド
現在の行を最後に変更したコミット	git blame
そのコミットのメッセージと差分	git show
ある行の範囲が、過去にどう変わったか	git log -L
ある文字列が追加・削除された履歴	git log -S
特定のパターンに一致する行の変更	git log -G

ただし、コミットが見つかっただけで変更理由まで確定するわけではありません。差分やメッセージを手掛かりに、Pull Requestや関連課題、当時の仕様書まで確認する必要があります。

今回の前提

WindowsのPowerShellから、Git導入済みのローカルリポジトリを調べます。コマンドの基本動作はPowerShell 7.6.9、Git 2.54.0.windows.1で、既存の履歴を読み取って確認しました。

以下のファイル名、行番号、コミットID、氏名、日時、出力は説明用の例です。同じ履歴を持つサンプルリポジトリを配布するものではないので、手元で試す場合は調査対象に置き換えてください。

まずリポジトリのルートフォルダーをPowerShellで開き、状態を確認します。

git status

未commitの変更があると、画面で見ている行番号とcommit済みのファイルの行番号がずれることがあります。今回はHEAD、つまり現在のブランチの先端コミットにあるコードを調べます。履歴を調べるために、作業中の変更を取り消す必要はありません。

結果が長く、ページャーで表示された場合はqで終了できます。

git blameで、対象行の最終変更を調べる

git blameは、ファイルの各行について、最後に変更したコミットとAuthorなどを表示します。-L 開始行,終了行を付けると、調べる範囲を絞れます。

例えば、app/Services/EmployeeService.phpの120〜123行目に、次の処理があるとします。LaravelのEloquentを使ったコードの抜粋です。

$query = Employee::where('customer_id', $customerId)
    ->where('invalid', 0)
    ->where('updated_at', '>', $lastSyncAt)
    ->get();

「更新日時の条件はいつ追加されたのか」を調べたいので、この範囲を表示します。

git blame -L 120,123 HEAD -- app/Services/EmployeeService.php

HEADを明示しているので、未commitの編集内容ではなく、先端コミットのファイルが対象です。--以降はファイルパスとして指定しています。

出力は次のような形になります。読み方を示すための架空の例です。

a1b2c3d (Tanaka 2025-08-12 10:30:00 +0900 120) $query = Employee::where('customer_id', $customerId)
e5f6a7b (Suzuki 2025-09-03 14:15:00 +0900 121)     ->where('invalid', 0)
f9a8b7c (Sato   2026-01-20 09:20:00 +0900 122)     ->where('updated_at', '>', $lastSyncAt)
a1b2c3d (Tanaka 2025-08-12 10:30:00 +0900 123)     ->get();

左から、短縮されたコミットID、Author名、Author日時、行番号、コードです。この例では、122行目を最後に変更したコミットはf9a8b7cと分かります。

ここで分かるのは、その行の最後の変更です。条件の追加後に整形や別の編集が入っていれば、そのコミットが表示されることもあります。条件が最初に追加された時期と同じかどうかは、次の差分で確認します。

git showで、何が変わったか確認する

git showにコミットIDを渡すと、コミットメッセージと差分を表示できます。次のIDは、実際に見つかったものへ置き換えてください。

git show f9a8b7c

調査中のファイルだけに絞りたい場合は、パスも指定します。

git show --format=fuller f9a8b7c -- app/Services/EmployeeService.php

例えば、次の差分があれば、このコミットで更新日時の条件が追加されたことを確認できます。

 $query = Employee::where('customer_id', $customerId)
     ->where('invalid', 0)
+    ->where('updated_at', '>', $lastSyncAt)
     ->get();

差分の先頭の+は追加された行、-は削除された行です。コミットメッセージに課題番号やPull Request番号が書かれていないかも確認します。

ファイルを絞った表示は読みやすいですが、背景を調べるときは最初のgit showで同じコミットの他のファイルも見ておくとよいです。関連するテストや呼び出し元の変更が、判断の手掛かりになることがあります。

補足：AuthorとCommitterは別の情報

--format=fullerでは、Author・AuthorDateと、Commit・CommitDateを確認できます。前者は変更の作成者とその日時、後者はそのコミットを記録した人と日時です。

例えば、特定のコミットの変更を現在のブランチへ取り込む操作であるcherry-pickでは、Authorを引き継ぎつつCommitterが変わる場合があります。どちらもGitに記録された情報なので、表示名だけで実作業者を厳密に証明したり、日時を実際の作業時間と決め付けたりはできません。

もっと前の変化を追うならgit log -L

git log -Lは、指定した行の範囲が過去にどう変わったかを、差分付きでたどるための指定です。blameで見つかったのが整形だけのコミットだった場合などに、さらに前の変更を確認できます。

git log -L 120,123:app/Services/EmployeeService.php

この場合、行番号はHEADのファイルを基準に指定します。過去の行番号を自分で毎回計算するのではなく、Gitがその範囲の変化を追います。

特定のコミットを起点にしたい場合は、次のように指定します。

git log f9a8b7c -L 120,123:app/Services/EmployeeService.php

今度はf9a8b7c時点の120〜123行目が対象です。その時点にファイルと行の範囲が存在する必要があります。-Lではファイルパスをコロンの後ろに含めるので、通常のファイル検索のように-- ファイルパスを追加しません。

コードが大きく書き換わっていると、意図した範囲を追えない場合もあります。範囲を小さくするか、次の文字列検索に切り替えてみます。

行が消えていても探せるgit log -S・-G

既に削除された条件は、現在の行を表示するblameだけでは探しにくいです。行番号が分からなくても、使われていた文字列を覚えていれば、履歴を検索できます。

-S：文字列の出現回数が変わったコミット

git log -p -S 'invalid' -- app/Services/EmployeeService.php

-Sは、指定文字列の出現回数が変わった差分を持つコミットを探します。-pは差分を表示する指定です。invalidという文字列を含む条件の追加・削除を調べたい場合に使えます。

一方、同じファイル内で文字列が移動しただけで出現回数が変わらなければ、その変更は検索に掛からないことがあります。

-G：追加・削除された差分行を正規表現で検索

git log -p -G 'where.*invalid' -- app/Services/EmployeeService.php

-Gは、追加・削除された差分行が、指定した正規表現に一致するコミットを探します。whereの後にinvalidを含む行、という条件で検索しています。

例えば、同じ条件を次のように書き換えたとします。

-    ->where('invalid', 0)
+    ->where('invalid', '=', 0)

この差分だけならinvalidの数は変わらないので、-S 'invalid'では見つかりません。-G 'where.*invalid'なら変更された行に一致します。「追加された時期」と「その行が編集された履歴」で、使い分けるとよいかと思います。

PowerShellの例では、検索文字列をシングルクォートで囲んでいます。今回はinvalidなどの単純な文字列ですが、$や引用符を含むコードを検索するときは、シェルの展開にも注意してください。

これらの例は、現在のブランチの先端からたどれる履歴を検索します。別のブランチで行われた変更が、現在の履歴にも含まれているとは限りません。

ファイル全体や、改名前の履歴を見る

まずファイル全体の変更を順に読みたいなら、次の形で十分です。

git log -p -- app/Services/EmployeeService.php

改名前の履歴も調べたい場合は、--followを付けます。

git log --follow -p -- app/Services/EmployeeService.php

--followは単一ファイルを対象に改名を追う指定です。ファイルの分割・統合や大幅な書き換えまで、すべて追跡できるわけではありません。

また、blameの結果が整形や移動に引っ張られている場合は、次の指定も試せます。

git blame -w -M -C HEAD -- app/Services/EmployeeService.php

• -w：空白の変更を無視して比較する
• -M：同じファイル内の行の移動・コピーも検出する
• -C：他のファイルからの移動・コピーも一定条件で検出する

移動の検出には条件やしきい値があるので、指定を付ければ必ず元のコミットに戻れる、というものではありません。差分の内容も合わせて判断します。

GitHub・Bitbucket Cloudの画面から調べる

GitHubのBlame

1. リポジトリで調査対象のブランチを選び、ファイルを開きます。
2. ファイル内容の上にある「Blame」を開きます。
3. 対象行に対応するコミットメッセージを選び、コミットの差分を確認します。
4. 関連するPull Requestが表示される場合は、その説明やレビューも確認します。メッセージに課題番号があれば、リンク先も調べます。

GitHubでは、.git-blame-ignore-revsの指定によって、一部のコミットをBlame表示から除外していることがあります。除外中の案内が表示されていたら、その条件も確認してください。操作はGitHub公式のファイルと行別履歴の説明を参照できます。

Bitbucket CloudのAnnotate／Blame

1. リポジトリの「Source」から調査対象のブランチとファイルを開きます。
2. ファイルの「…」メニューから「Annotate／Blame」に相当する行別履歴の表示を開きます。
3. 対象行のコミットIDを確認し、コミット詳細で差分を調べます。
4. 関連するPull RequestやJiraの課題があれば、そこで変更の背景を確認します。

この導線は、AtlassianのBitbucket CloudのAnnotate／Blameに関する公開課題に記載された操作に基づきます。メニューの文言や配置は変わる場合があります。ファイル全体の履歴は、公式チュートリアルのファイル履歴の案内も参考にしてください。

行別表示が開けない場合は、ローカルのgit blameでコミットIDを調べ、画面側でそのコミットの差分を見る方法もあります。Bitbucket Cloudのファイル履歴では改名前の履歴を追えない場合があり、Atlassianも改名を含む履歴をローカルで確認する方法を案内しています。

「いつ変わったか」と「なぜ変えたか」を分けて記録する

最初の例であれば、次の順に確認します。

1. 更新日時の条件がある行を、blameで調べる。
2. 見つかったコミットをshowで開き、条件の追加なのか、後からの編集なのかを確認する。
3. 必要ならlog -Lや-S・-Gでさらに前へ進む。
4. Pull Requestや課題で、条件を追加した目的と期待する動作を確認する。

例えば「コミットXで更新日時の条件が追加された」は差分から確認できる事実です。一方、「同期処理の負荷を下げるために追加された」は、コードだけからは確定できません。課題やレビューで確認できなければ、そう見えるという推測として残しましょう。

履歴が見つからない場合も、変更がなかったとは限りません。別ブランチ、改名、複数のコミットの変更を一つにまとめるSquash、浅いcloneなど、手元で見られる範囲も確認の必要がある場合もあります。

行の最終変更はblame、その内容はshow、過去の変化はlog。ここを起点に関連資料へ進むと、現在のコードができた経緯を調べやすくなるかと思います。

参考資料

• Git公式：git blame
• Git公式：git show
• Git公式：git log