How does git blame work and when is it useful?
Learn how git blame annotates each line with its commit, author, and date, plus -L, -M and -C flags to trace regressions and code context fast.
Expected Interview Answer
git blame annotates each line of a file with the commit, author, and date that last modified it, so you can see exactly who changed a given line and when.
Git walks the file's history and attributes every line to its most recent introducing commit, printing the short hash, author, timestamp, and line content side by side. It is invaluable for understanding why a line exists — you can jump from the blamed commit to its message, related changes, and the pull request that introduced it. Options like -L limit blame to a line range, and -C / -M follow lines across copies and moves so refactors don't hide the true origin.
- Pinpoints who last changed a specific line and when
- Provides context via the introducing commit message
- Speeds up debugging by tracing a regression to its source
- Follows moved or copied lines with -M and -C
- Helps identify the right reviewer or domain expert to ask
AI Mentor Explanation
git blame is like a ball-by-ball commentary log where every run on the scoreboard is tagged with which batter struck it and in which over. When you see an odd total, you don't guess — you trace the exact delivery and player responsible, just as blame ties each line of code to the precise commit and author that produced it.
Step-by-Step Explanation
Step 1
Run blame on a file
git blame path/to/file.js prints every line prefixed with its introducing commit, author, and date.
Step 2
Narrow to a range
Use -L 40,60 to blame only lines 40–60 when investigating a specific region.
Step 3
Follow moves and copies
Add -M to detect lines moved within the file and -C to follow lines copied from other files.
Step 4
Inspect the commit
Copy the short hash and run git show <hash> to read the full message, diff, and context.
Step 5
Trace deeper
If a line was only reformatted, re-blame from before that commit (git blame <hash>^ -- file) to find the real origin.
What Interviewer Expects
- Defines blame as per-line attribution to a commit and author
- Knows it shows hash, author, and date alongside each line
- Mentions using it to trace regressions and understand intent
- Aware of -L for line ranges and -M/-C for moved/copied lines
- Understands you follow the commit hash to the full context
Common Mistakes
- Treating blame as assigning fault rather than finding context
- Stopping at a formatting commit instead of tracing the real origin
- Not knowing -L to focus on a specific line range
- Forgetting -M/-C so refactors hide the true author
- Confusing git blame with git log for whole-file history
Best Answer (HR Friendly)
“git blame shows, line by line, who last changed each part of a file and when. Developers use it to understand why a piece of code exists and to trace a bug back to the change that caused it, so despite the name it's really about context, not fault.”
Code Example
# Annotate every line with commit, author, and date
git blame src/app.js
# Focus on just lines 40-60
git blame -L 40,60 src/app.js
# Follow moved (-M) and copied (-C) lines so refactors don't hide authorship
git blame -M -C src/app.js
# Jump from a blamed hash to its full context
git show a1b2c3dFollow-up Questions
- How do you make git blame ignore whitespace-only or formatting commits?
- What is the difference between git blame and git log -p for a file?
- How do the -M and -C flags change blame results after a refactor?
- How can you blame a file as it existed at a past commit?
- Why is 'blame' considered a misleading name for this command?
MCQ Practice
1. What does git blame primarily show?
git blame annotates each line of a file with the last commit, author, and date that modified it, giving per-line attribution.
2. Which flag limits git blame to a specific line range?
The -L option (e.g. -L 40,60) restricts blame to the given line range, useful for focusing on a specific region.
3. Why add -M and -C to git blame?
-M detects lines moved within a file and -C detects lines copied from other files, so refactors don't wrongly attribute lines to the moving commit.
Flash Cards
What does git blame do? — Annotates each line of a file with the commit, author, and date that last modified it.
Which flag focuses blame on a line range? — -L, e.g. git blame -L 40,60 file.js.
What do -M and -C add to blame? — -M follows moved lines, -C follows copied lines, so refactors don't hide the true author.
How do you skip a formatting-only commit in blame? — Re-blame from before it: git blame <hash>^ -- file, to find the line's real origin.
Is git blame about assigning fault? — No — it's about context: tracing why a line exists and finding the change that introduced it.