- 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
git blame annotates a file line by line with the commit, author, and timestamp that most recently changed each line.
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.