あるファイルの100行目の記述について、なぜこのコードが書かれたのかという経緯を調べたい。git blameで該当行のコミットハッシュを取得した後、「その変更が含まれたプルリクエストの議論や、さらにその行が以前どう書かれていたか」まで遡って調査する手順として最も適切なものはどれか。

解説

正解は2番です。git blameは「その行を最後に変更したコミット」しか教えてくれないため、経緯を深く追うには2段階の作業が必要になります。まず取得したコミットハッシュからGitHub上でPR(プルリクエスト)をたどって議論や意図を読み、次にその変更より前の状態に対して再度blameを実行することで「さらに前は誰がどう書いていたか」を遡っていきます。1は出力に直接PR番号は含まれないため誤り、3はlogのコメント内容で行番号を探すのは現実的でなく誤り、4はGitHubのBlameビューも過去の状態を表示できるしreflogはローカル操作履歴なので誤りです。git blameが教えてくれること・くれないことgit blameは各行の横に「最後にその行を変更したコミット・著者・日時」を表示するコマンドです。ただし重要なのは、blameが指すのは「最後の変更」であって「その行が最初に書かれた瞬間」ではないという点です。たとえばフォーマッタがインデントを直しただけのコミットがblameに出てきて、本質的な変更履歴が埋もれてしまうことがあります。コミットより前の状態を遡るには経緯を追うには「そのコミットの直前の状態」に対して再度blameを走らせます。コミットハッシュの後ろに ^ を付けると「その一つ前の親コミット」を指します。# 100行目を最後に変更したコミットを確認 git blame -L 100,100 file.txt # そのコミット(abc1234)の直前の状態で、同じ行が何行目にあたるか調べつつblame git blame abc1234^ -L 95,105 file.txt-Lオプションで行範囲を絞ると出力が見やすくなります。ただしリファクタで行番号がずれていることも多いので、前後数行を含めて確認するのがコツです。GitHub側でPRと議論まで追うローカルのblameでハッシュが分かったら、GitHubで https://github.com/owner/repo/commit/<hash> を開きます。そのコミットページに「This commit was part of pull request #123」という表示があれば、PRに飛んでレビューコメントや設計議論を読めます。GitHub上のBlameビュー(ファイル画面右上の「Blame」ボタン)には「View blame prior to this change」というボタンがあり、ワンクリックで一つ前のblameに遡れるので、ターミナルを使わずに追跡する場合はこちらが便利です。実務でのコツwhitespace系の変更を無視したい場合は git blame -w を使う行の移動やコピー元を検出したい場合は -M や -C オプションが有効PRが見つからない古いコミットは、コミットメッセージのissue番号(#456など)から関連議論をたどる「なぜこの実装なのか」を知ることは、安易な書き換えでバグを生むのを防ぐ最も確実な方法です。