プロジェクトの歴史を探る：Git Log、Diff、Blame コマンド

Git の log、diff、blame コマンドを使ってプロジェクトの歴史を探ることで、コードベースがどのように現在の状態に至ったかを理解できます。デプロイが壊れたり、設定が変わったり、ファイルに見覚えがない場合、これらのコマンドは推測ではなく明確な手がかりを提供します。

すべての Git オプションを暗記する必要はありません。まずは信頼性の高いパターンをいくつか覚え、状況に応じて詳細を追加していきましょう。

Git Log でストーリーを読む

git log は現在のブランチのコミット履歴を表示します。デフォルトでは、コミットハッシュ、作者、日付、コミットメッセージが出力されます。便利ですが、簡単なタイムラインだけが必要な場合には情報が多すぎることがあります。

日常業務では、次のフォーマットがスキャンしやすいです：

git log --oneline --decorate --graph --all

これにより、コンパクトなコミットリスト、ブランチラベル、マージの簡易グラフが表示されます。ブランチが main から分岐しているかどうか、マージコミットが変更のグループをもたらしたかどうかを確認したい場合に特に役立ちます。

特定のファイルを調査する必要がある場合は、ログをそのパスに限定します：

git log --oneline -- path/to/file

これで「最近このファイルに触れたのは誰で、なぜか」という一般的な質問に答えられます。そこから、次のコマンドでコミットを開けます：

git show <commit>

git show はコミットメッセージとそのコミットのパッチを表示します。ログエントリが調査中の問題に関連しているように見える場合の次のステップとして適しています。

実用的な例として、設定変更後にアプリケーションがタイムアウトし始めたとします。git log --oneline -- config/nginx.conf を実行し、「increase upstream timeout」というコミットを見つけ、git show で調査します。これにより、変更された正確な行とコミットメッセージから意図がわかります。

関連するワークフローの基本については、Git ステージとコミットのマスターを参照してください。

Git Diff で変更を比較する

git diff は2つの状態間の変更を表示します。これは、コミット前、ブランチのレビュー前、またはローカル編集が動作変更を引き起こしたかどうかを確認するときに使用するコマンドです。

最も一般的なバージョンは：

git diff

これは作業ツリーと最後にコミットされたバージョンを比較します。簡単に言うと、ステージングされていない編集を表示します。

すでに git add でファイルをステージングした場合は、次を使用します：

git diff --staged

これにより、次のコミットに含まれる内容が表示されます。これは、誤った空白の変更、デバッグプリント、無関係な編集がプロジェクト履歴の一部になる前にキャッチできるため、身につけるべき最良の習慣の1つです。

2つのブランチを比較することもできます：

git diff main..feature-branch

これにより、main と比較して feature-branch で異なる内容が表示されます。出力が大きすぎる場合は、1つのファイルに絞り込みます：

git diff main..feature-branch -- src/server.js

パッチをレビューするときは、最初にファイル名を読み、次に変更されたブロックを読みます。Git は削除された行を -、追加された行を + でマークします。近くの変更されていない行はコンテキストであり、変更ではありません。

便利なトラブルシューティングパターンは、最後に正常だったコミットと現在のコミットを比較することです：

git diff <good-commit>..HEAD

これだけで壊れた行がわかるわけではありませんが、検索範囲を提供します。差分が小さい場合、原因は明らかなことが多いです。大きい場合は、git bisect、テスト、または集中したレビューが必要になるかもしれません。

Git Blame で行の所有権を見つける

git blame はファイルの各行を最後に変更したコミットを表示します。名前にもかかわらず、このコマンドは責任を割り当てるためのものではありません。コンテキストを見つけるためのものです。

次のように使用します：

git blame path/to/file

各行にはコミットハッシュ、作者、日付、内容が含まれます。行が疑わしい場合は、コミットハッシュをコピーして調査します：

git show <commit>

これにより、より良い質問ができるようになります。「なぜこれがここにあるのか」と尋ねる代わりに、「これは互換性修正、パフォーマンス回避策、緊急パッチのために追加されたのか」と尋ねることができます。

大きなファイルの場合、blame 出力はノイズが多いことがあります。ほとんどのターミナルではページングできますが、行範囲を指定することもできます：

git blame -L 40,80 path/to/file

これにより調査が集中します。エラースタックトレースが特定の行を指している場合に最適です。

1つの詳細が重要です：git blame は行を変更した最新のコミットを表示しますが、必ずしも基礎となるアイデアを導入したコミットではありません。フォーマットコミットは blame を役に立たなくする可能性があります。チームにフォーマットのみのコミットがある場合は、以前の履歴を調査するか、ignore-revs 設定を使用する必要があるかもしれません。

実用的な履歴調査の流れ

何かが変更され、理由がわからない場合は、コマンドを一定の順序で使用します。

git status でローカル編集があるか確認します。
git diff または git diff --staged で未コミットの変更を調査します。
git log --oneline -- path/to/file でファイルの最近のコミットを見つけます。
git show <commit> で可能性のある変更を調査します。
git blame -L start,end file で1行のコンテキストが必要な場合に使用します。

これにより、いきなり大規模な履歴検索に飛び込むのを防げます。ローカルで何が変わったかから始め、その後ブランチとファイルの履歴に範囲を広げます。

例えば、Docker ビルドが環境変数の消失で失敗し始めたとします。まずローカルの差分を確認します。それがクリーンなら、Dockerfile とデプロイ設定のログを調査します。変数名を変更したコミットを見つけた場合、git show でアプリコードも更新されたかどうかがわかります。1つの参照が不明瞭な場合、git blame で最後に変更された時期がわかります。

助けを求めるタイミング

Git 履歴コマンドは履歴を調査するだけで書き換えないため、安全に実行できます。それでも、1つのコミットから強い結論を導き出す前に、チームメイトに相談してください。行はリファクタリング中に変更されたり、別のファイルからコピーされたり、コードからは明らかでない本番問題を回避するために更新された可能性があります。

また、共有ブランチで rebase、reset、filter-repo などの履歴書き換えコマンドを使用する前には一時停止すべきです。これらは便利なツールですが、調整なしで使用すると他の開発者に混乱を引き起こす可能性があります。

Git log、diff、blame はプロジェクト履歴への実用的な可視性を提供します。log でタイムラインを見つけ、diff で変更を比較し、blame で行レベルのコンテキストを追跡します。これらを組み合わせることで、「何かが変わった」を具体的なコミット、ファイル、理由に変え、行動に移せます。