- Developers who already know basic commit and branch actions
- Readers who want to understand command boundaries and risk
Command Reference
git blame
Track which commit last changed each line in a file, making it useful for recovering context around why a line looks the way it does now.
- A basic mental model of worktree, index, and commits
- Comfort reading `git status` and a small commit graph
- Using local cleanup commands on already shared history
- Continuing to rewrite before confirming a recovery path
Citations & Further Reading
- Git blame [Official]
- Git Tools Debugging with Git [Book]
What you will learn
- Understand the core purpose of git blame
- Master the basic usage and common options of git blame
- Track which commit last changed each line in a file, making it useful for recovering context around why a line looks the way it does now.
- Understand key concepts: Common examples
- Know when to use this feature and when to avoid it
git blame annotates a file line by line with the commit, author, and timestamp that most recently changed each line.
Start with a problem
You're working in a Git repository and need to perform a specific task — but you're not sure which command or option is the right fit, or what this command can and cannot do.
Common examples
git blame src/app.ts
git blame -L 20,60 src/app.ts
When it helps
- understanding where a line came from
- jumping from current code back to the relevant commit
- reconstructing context around a behavior change
Best practice
Use blame together with:
git show <commit>git log -- <file>git diff
Blame tells you who last touched a line, but not always the full story behind why the change happened.
What problem this command solves in a workflow
In the workflow, git blame is mostly a “inspect first, decide second” command. It usually does not rewrite history by itself; instead, it helps you confirm the current state of the working tree, index, refs, or commit objects.
Typical use cases
- Use
git blamebefore changing files or history so you have observable evidence first. - Put
git blameinto review, debugging, and incident-analysis flow so the team can align on the same context. - When you need to explain why the repository looks the way it does, let
git blamesurface verifiable information first.
Diagram view
Working treeIndexCommit historyRefs
Console outputDiff contextDecision signal
If the output looks wrong, the first thing to question is usually the scope you inspected, not whether the command “worked”.
Special cases and boundaries
- Most inspection commands do not mutate history, but their output still depends on which HEAD, path, range, or ref you asked them to inspect.
- If
git blameshows something unexpected, first verify whether you are looking at the working tree, the index, the current branch, or a historical commit. - Combining
git blamewithgit status,git log, andgit showis usually safer than trusting a single output in isolation.
Try it yourself
- Practice the git-blame command in a test repository and observe state changes before and after
- Experiment with different options and compare the output differences
- Simulate a real scenario where you would need to use this, and walk through the full process
Further reading
Keep going on the same topic: