【Git入門】git blame で変更履歴を確認する方法を初心者向けに解説

はじめに

ソフトウェア開発では、プログラムの変更履歴を調べたい場面がいろいろとあります。
特に、どのタイミングで誰がどの行を編集したのかを知りたいときはないでしょうか。
Gitには便利なコマンドがたくさんありますが、その中でもgit blameは、ファイルの特定の行を編集した人やコミット内容を調査する際に活用されやすいコマンドです。

作業中に「この一行はなんでこうなっているのだろう？」と思ったら、実際にgit blameを使ってみると、変更の経緯がわかるかもしれません。
ここでは、git blameの基本的な使い方から実務上どのように役立つかまで、初心者の方に向けて丁寧に解説していきます。

この記事を読むとわかること

• git blameコマンドの基本的な役割
• git blameで得られる情報の読み方
• オプションを使った便利な調べ方の例
• 実務でgit blameをどのように活用できるか

これらを理解すると、コードの変更履歴を効率よく把握できるようになります。

git blameとは何か

git blameは、Gitリポジトリ内のファイルに対して「いつ・誰が・どのコミットで・どの行を変更したのか」を調べるコマンドです。
コードレビューやバグ調査のときに「ここを修正したのは誰だろう？」と確認したい場面で役立ちます。

また、「blame」という名前は少し強い言葉ですが、「犯人探し」というよりも、コード変更の意図や経緯を知るために使うと考えるとよいでしょう。
コードがどのように進化してきたかを理解するうえで頼りになるコマンドです。

基本的な仕組み

git blameコマンドを実行すると、ファイル内の行ごとに「コミットID」「作者」「日付」「実際のコード行」が表示されます。
それを見れば、いつ誰がその行を変更したのかを一目で確認できるようになっています。

なぜ初心者でも知っておくと便利なのか

Gitの基本コマンドといえば、git commitやgit pushなどが先に思い浮かぶかもしれません。
しかし、複数人で作業をしていると、原因不明のバグや「なぜこういう書き方をしているのか？」と疑問に思う箇所が出てくるかもしれません。
そんなときは「誰が、どんな理由で、いつ書いたコードなのか」を追えると安心です。

初心者の方はとくに、他の人のコミットに対して怖がりがちですが、git blameを通してコードの歴史を知ると、バグ修正や理解の大きな手がかりになるはずです。

git blameの基本的な使い方

ここでは、git blameを使ってファイルの変更履歴を調べる流れを簡単に紹介します。

コマンドの構文

コピー
git blame [オプション] <ファイル名>

最もシンプルな形で使う場合は、以下のように入力します。

コピー
git blame main.js

たとえば上記を実行すると、main.jsの各行に対して、以下のような情報が表示されます。

• コミットID（先頭数文字で短縮表示される場合が多い）
• 作成者（Author）
• 日時（Date）
• 行番号
• 実際のコード

出力例

ここでは、仮のファイルmain.jsに対してgit blameを実行した場合のイメージです。
実際の結果はリポジトリやファイルの内容によって異なります。

コピー
commit1a2b (Alice        2025-02-05 15:03:42 +0900  1) console.log("Hello World!");
commit1a2b (Alice        2025-02-05 15:03:42 +0900  2) 
commit3c4d (Bob          2025-02-10 10:25:11 +0900  3) function greet(name) {
commit3c4d (Bob          2025-02-10 10:25:11 +0900  4)   return `Hello, ${name}!`;
commit3c4d (Bob          2025-02-10 10:25:11 +0900  5) }
commit5e6f (Charlie     2025-02-15 09:00:03 +0900  6) console.log(greet("Alice"));

上記のように、各行の先頭部分にコミットID・作者・日時が表示され、その後に実際のコードが続きます。
これを見れば、console.log(greet("Alice")); という行はCharlieさんが2025年2月15日のコミットで追加したとわかります。

よく使うオプションの例

git blameには多くのオプションがありますが、初心者の方にもわかりやすいものをいくつか紹介します。
必要に応じて使い分けると、調査効率が上がります。

特定の行範囲を調べる：-L

大きなファイル全体ではなく、一部の範囲だけを調べたいときは-Lオプションを使います。
行番号を指定することで、該当範囲のみの履歴を表示できます。

コピー
git blame -L 10,20 main.js

上記の例では、main.jsの10行目から20行目までに限定して変更履歴を確認できます。
一度にすべてを見るのが大変な場合や、特定の箇所だけ原因を追いたいときに便利です。

詳細な情報を表示する：-p

-pオプションを付けると、コミットIDや作者、メールアドレス、日付など、より詳細な情報が出力されます。
フォーマットが少し複雑になりますが、綿密に調べたい場合に使うとよいでしょう。

コピー
git blame -p main.js

日付表示を見やすくする：--date

標準のフォーマット以外で日付を表示したいときは、--dateオプションが有効です。
たとえば、ISO形式で表示したい場合は以下のようにします。

コピー
git blame --date=iso main.js

これにより、2025-02-10 10:25:11 +0900 といったISO形式の日付が出力され、タイムゾーン情報も含めて読みやすくなります。

git blameの実行例

ここでは、実行例をもう少し詳しく紹介します。
初心者の方がよくやるミスも含めて解説しますので、参考にしてみてください。

コピー
# ファイル名を間違って指定してしまった例
git blame amin.js

もしスペルを間違えてしまうと、次のようなエラーが表示されるかもしれません。

コピー
fatal: no such path 'amin.js' in HEAD

この場合は単純にファイル名が間違っている可能性が高いので、正しいファイル名を確認して再度実行してみましょう。
誤って大文字・小文字を混在させることも多いので注意してください。

コピー
# 正しいファイル名で再度実行
git blame main.js

すると、ファイルの各行について、コミットIDや作者、日付、実際のコードが表示されるようになります。
これで気になる箇所がどのコミットでどのように修正されたかを確認できます。

git blameを実務でどのように活用できるか

実務でもgit blameは頻繁に使われます。
特に、チーム開発では「誰がどのコードを書いたか」だけでなく「そのコードがどんな経緯で生まれたか」を探る際の手がかりになります。

コードレビューでの確認

レビュー担当の方が気になった行を、コミットメッセージや作者などを合わせて調べることがあります。
git blameで調査した後、さらにgit logやgit diffなどを組み合わせて、修正の詳細を深掘りできるでしょう。

バグ調査や緊急対応

リリース後にバグが見つかった場合、問題の行がどのコミットで追加・変更されたかを調べると、素早く原因にたどり着きやすくなります。
もし複数人で作業していても、コミット者に詳細を聞くなど、適切なアクションを取りやすくなります。

ドキュメントや仕様の補完

実務ではコードだけでなく、仕様書やドキュメントがきちんとそろわないまま実装が行われる場合があります。
そうしたとき、特定の機能や処理がいつ追加されたのかを把握できると、後からドキュメントを充実させる際に役立ちます。

git blameを使う上で気をつけたいポイント

git blameは有用ですが、使う際に以下の点を意識しておくとよりスムーズです。

犯人探しを目的にしない

同僚や過去の自分を責めるのではなく、コードの歴史を理解して前に進むために使いましょう。

マージコミットやリベースによる変更

複雑なブランチ戦略やリベースを行った場合、コミットがまとめられたり書き換えられたりしていることがあるかもしれません。
そのため、過去の履歴が単純には追いきれない場合もあります。

大幅リファクタリングやファイルの移動

ファイル構成が変わると、単純なblame情報では正しい変更者が見えにくくなる場合があります。
そのときはgit logやgit diffで並行して履歴を洗い出してみてください。

まとめ

git blameコマンドは、Gitリポジトリで作業をしているときに「どの行が、いつ、誰によって編集されたのか」を知るためにとても役立ちます。
初心者の方にも理解しておくと便利なコマンドなので、バグ調査やコードレビューなどの場面で活用してみるのはいかがでしょうか。

細かいオプションも多数ありますが、まずはシンプルな使い方をマスターするといいでしょう。
ファイルの特定箇所に関する履歴を調べたいときは**-L**、詳細なフォーマットが必要なときは**-p**、日付の表示形式を変えたいときは**--date**のように、目的に応じて追加してみてください。

実務では、git blameで得られる情報をもとに、コミットメッセージや作者、関連するチケット番号などを合わせて調査します。
「いつ書かれたコードなのか」を理解するだけでも、新しい開発者が既存のコードを読むときに大いに助けになってくれるでしょう。