git blame: Finding Who Changed Which Line and When

When you're staring at a confusing or buggy line of code and need to understand its history — who wrote it, when, and as part of which change — `git blame` gives you exactly that, annotating every single line of a file with the commit that last modified it.

Learning Objectives

Run git blame on a file to see line-by-line authorship and commit information.
Interpret git blame output: commit hash, author, date, and line content.
Use git blame on a specific line range for a large file.
Understand the appropriate, constructive use of git blame in a team setting.

Key Terms to Know Before Learning git blame

git blame: A command that annotates each line of a specified file with the hash, author, and date of the commit that most recently changed that line.
Line-level history: The record of exactly which commit last modified each individual line in a file, as opposed to file-level history.
-L flag: A git blame option that restricts output to a specific line range, useful for large files.
Blame ignore-revs: A configuration allowing certain commits (like large formatting-only changes) to be skipped when attributing blame, showing the more meaningful prior change instead.

How git blame Actually Works

Running `git blame` on a file produces one annotated line per line of the file's content:

```
git blame app.js
```

Each output line begins with an abbreviated commit hash, the author's name, the date of that commit, the line number, and finally the actual line content — for example:

```
a1b2c3d (Asha Mehta 2026-06-12 14) function validateLogin(user) {
9f8e7d6 (Rohit Sharma 2026-05-30 15) if (!user.email) return false;
```

This tells you, at a glance, that line 14 was last touched by Asha in a commit from June 12th, while line 15 was last touched by Rohit back in May. Note the important nuance: `git blame` shows the *most recent* commit to touch each line — not necessarily the commit that originally created it. If a line was written in the first commit and never touched again, blame correctly points back to that original commit; but if it's been edited five times since, blame shows only the fifth (most recent) edit.

For large files, you can restrict output to a specific line range using `-L`:

```
git blame -L 40,60 app.js
```

This shows blame annotations only for lines 40 through 60, which is far more practical than scrolling through blame output for an entire thousand-line file when you only care about one function.

Once you've identified the relevant commit hash from blame output, the natural next step is combining it with `git show <hash>` (this module's first lesson) to see the full context of that specific change — blame tells you *which* commit, and `git show` tells you *what and why*.

A word on responsible use: `git blame`'s name is unfortunately adversarial-sounding, but its real purpose is understanding history and context — not assigning fault. In a professional team setting, it's best used to understand *why* a line exists (perhaps referencing a bug fix or a specific requirement mentioned in that commit's message), not to publicly call out a teammate for a mistake. Many teams also configure a 'blame ignore list' for large mechanical changes (like a whole-file reformatting commit) so that blame skips over those and shows the more meaningful prior change instead.

git blame: Visual Walkthrough

Show a code file with 4 lines, each annotated on the left with a small tag: Line 1 tagged 'a1b2c3d — Asha — Jun 12', Line 2 tagged '9f8e7d6 — Rohit — May 30', Line 3 tagged 'a1b2c3d — Asha — Jun 12', Line 4 tagged '3c4d5e6 — Meera — Apr 02'. Add a callout arrow from the 'a1b2c3d' tag pointing to a second box showing 'git show a1b2c3d' output with the full commit message and diff, illustrating the blame → show workflow.

Command vs Purpose: Key Differences

Command	Purpose
git blame <file>	Show line-by-line authorship for the entire file
git blame -L 40,60 <file>	Restrict blame output to lines 40 through 60 only
git show <hash from blame>	View full metadata and diff of the commit blame points to
git blame -w <file>	Ignore whitespace-only changes when attributing blame

git blame: Command Syntax and Examples

# Full-file blame
git blame app.js

# Example output line:
# a1b2c3d (Asha Mehta 2026-06-12 14:02:11 +0530  14) function validateLogin(user) {

# Blame only a specific line range (useful for large files)
git blame -L 40,60 app.js

# Ignore whitespace-only changes when determining blame
git blame -w app.js

# Follow up: inspect the full commit found via blame
git show a1b2c3d

Breaking Down the git blame Example

The full-file blame example shows the standard output format: commit hash, author, timestamp, line number, and the line's content. Restricting with `-L 40,60` is essential for large files where scrolling through the entire blame output for every line would be impractical. The `-w` flag is useful when a file has been reformatted (e.g., indentation changed) without meaningful content changes — without it, blame would misleadingly attribute every reformatted line to the formatting commit rather than the commit that last changed its actual content. Finally, piping the hash into `git show` completes the investigation by revealing the full commit message and diff behind that specific line.

How git blame Is Used on Real Engineering Teams

Developers investigating a production bug commonly run git blame on the exact function containing the bug to quickly identify who last touched it and reference the associated commit message for context.
Code review tools like GitHub and GitLab display blame-style 'Blame' views directly in their file browser UI, letting reviewers see line-level authorship without using the command line.
Teams that perform large-scale automated reformatting (e.g., applying a new code style tool across an entire codebase) commonly configure a .git-blame-ignore-revs file so that blame skips over that one mechanical commit and shows the more meaningful history underneath.
Onboarding engineers often use git blame combined with git show to understand the historical reasoning behind unusual or non-obvious code they encounter in an unfamiliar codebase.

git blame Interview Questions and Answers

Q1. What does git blame show, and what is a common misunderstanding about it?

git blame annotates each line of a file with the commit hash, author, and date of the most recent change to that line. A common misunderstanding is assuming it shows who originally wrote a line — it actually only shows the most recent commit to touch that line, which may be a much later edit, not the original author.

Q2. How would you investigate the history of just one function in a very large file?

Use the -L flag to restrict git blame to the relevant line range, such as git blame -L 40,60 app.js, rather than scrolling through blame output for the entire file.

Q3. How does git blame typically get used together with git show?

git blame identifies which commit hash last modified a specific line. Running git show <hash> on that identified commit then reveals the full commit message and diff, providing complete context for why that line was changed.

git blame Quiz: Test Your Understanding

1. What information does git blame show for each line of a file?

Only the line's current content
The commit hash, author, and date of the most recent change to that line
The total number of times the file has been edited
The file's creation date only

Answer: B. The commit hash, author, and date of the most recent change to that line

Explanation: git blame annotates every line with the commit hash, author, and date responsible for its most recent modification, alongside the line content itself.

2. Which flag restricts git blame output to a specific range of lines?

-R
-L
-N
-B

Answer: B. -L

Explanation: The -L flag, followed by a line range like 40,60, restricts git blame's output to only that portion of the file.

3. Does git blame always show the original author of a line?

Yes, always
No — it shows the author of the most recent change to that line, which may differ from who originally wrote it
Only for the first line of a file
Only if the file has never been edited

Answer: B. No — it shows the author of the most recent change to that line, which may differ from who originally wrote it

Explanation: git blame reflects the most recent modification to each line, not necessarily its original creation, since the line may have been edited multiple times since it was first written.

git blame: Common Mistakes Beginners Make

Assuming git blame identifies the original author of a line, when it actually only shows the most recent commit to modify it.
Running plain git blame on a huge file and being overwhelmed, instead of using -L to focus on a relevant line range.
Not using -w when a file has been reformatted, leading to misleading blame attribution pointing to formatting changes instead of meaningful content changes.
Using git blame to publicly assign fault to a teammate rather than to understand historical context and reasoning behind a change.

git blame: Exam-Ready Quick Notes

git blame <file>: shows commit hash, author, date for every line of a file.
git blame -L <start>,<end> <file>: restricts output to a specific line range.
git blame shows the most recent modifying commit per line, not necessarily the original author.
Commonly paired with git show <hash> for full context on a specific change.

git blame: Key Takeaways

git blame provides line-level authorship history, answering 'who last changed this specific line, and when'.
It shows the most recent modifying commit per line, not the line's original author, which is a critical distinction.
Combining git blame with git show turns a single suspicious line into a full understanding of its history and reasoning.

Frequently Asked Questions About git blame

Q1. What does git blame do?

It shows, for every line in a file, which commit most recently changed that line, along with the author's name and the date of that commit — giving you line-by-line history at a glance.

Q2. Does git blame show who originally wrote a line of code?

Not necessarily. It shows the most recent commit to modify that line. If the line has been edited multiple times since it was first written, blame will point to the latest edit, not the original author.

Q3. How do I use git blame on just part of a large file?

Use the -L flag with a line range, such as git blame -L 40,60 app.js, to restrict the output to only the lines you care about instead of the entire file.

Q4. Why would I combine git blame with git show?

git blame tells you which commit last changed a specific line. Running git show on that commit's hash then reveals the full commit message and complete diff, giving you the full context and reasoning behind that change.

Q5. Is it appropriate to use git blame to criticize a teammate?

No — despite its name, git blame is meant to help you understand history and context, not to assign fault. It's best used constructively, to understand why a piece of code exists before making changes to it.

Summary

`git blame` annotates every line of a file with the commit hash, author, and date responsible for its most recent change, making it the primary tool for understanding line-level history. It's important to remember that blame reflects the most recent modification to a line, not necessarily who originally wrote it. For large files, the `-L` flag restricts output to a specific line range, and `-w` can ignore whitespace-only changes to avoid misleading attribution after reformatting. Blame output is most powerful when combined with `git show <hash>`, which reveals the full commit message and diff behind a specific change — turning a single confusing line into complete historical context.