Git Blame — Wrong Developer Got Flagged in Postmortem

Teams use git blame to find who introduced a bug. But blame shows the LAST person to touch a line, not the ORIGINAL author. A formatting commit, a merge conflict resolution, or a whitespace fix all overwrite the blame trail. In the worst cases, the blame finger points at the wrong developer entirely. This guide covers how to read blame accurately, how to dig past cosmetic changes to find the real origin, and the production incident where blame misattribution nearly cost an engineer their reputation.

What Git Blame Actually Does

Git blame annotates each line of a file with metadata: the commit hash, author, date, and line number. It answers the question: "Who last touched this line, and in which commit?" This is not a forensic tool for assigning blame in a negative sense; it's a breadcrumb trail for understanding code evolution. When you run git blame on a file, you get a line-by-line breakdown. The output shows the commit SHA, author, timestamp, and line content. For example, git blame -L 10,20 src/app.js limits the output to lines 10 through 20. This is invaluable when you encounter a confusing line of code and need to understand its origin. However, remember that blame only shows the last modification. A line might have been moved or reformatted by a later commit, obscuring the original author's intent. Always check the full commit context before drawing conclusions.

cd /path/to/repo
git blame -L 50,60 config/database.yml

Reading Blame Output Like a Pro

The default blame output is dense. Each line starts with a commit hash (abbreviated), author name, timestamp, line number, and then the code. The hash is clickable in most terminals if you have a git browser configured. The author is the committer, not necessarily the original author (though usually the same). The timestamp is in ISO 8601 format with timezone. To make it more readable, use options like --date=short for YYYY-MM-DD or --date=relative for "3 weeks ago". You can also filter by author: git blame --author=Jane file. If you want to see the full commit hash, use --abbrev=40. For large files, pipe to less or use -L to focus on a region. Pro tip: combine with git log on the commit hash to see the full commit message and diff. This workflow is standard for code reviews and debugging.

git blame --date=short -L 1,10 README.md

Ignoring Whitespace and Moves with Git Blame

By default, blame considers any change to a line, including whitespace. This can be misleading when a file is reformatted (e.g., tabs to spaces) or when code is moved within the file. Use -w to ignore whitespace changes. For moved code, use --ignore-rev to skip a specific commit that only moved lines. You can also use --ignore-revs-file to list multiple commits. This is critical in projects that underwent a formatting overhaul. For example, if a commit changed all indentation from tabs to spaces, blame will show that commit for every line. Using -w will revert to showing the original author. Similarly, if a function was moved to a new file, blame on the new file will show the move commit. To find the original author, you need to blame the original file before the move.

git blame -w src/app.js
# Or ignore a specific commit that only reformatted
git blame --ignore-rev abc1234 src/app.js

Blame in Large Files: Performance and Strategies

Blame on a large file (e.g., 10k+ lines) can be slow because git walks the entire history for each line. To speed it up, limit the range with -L. If you need to blame the whole file, consider using git blame --porcelain for machine-readable output that is faster to parse. Another strategy: if you only care about recent changes, use --since to ignore commits older than a date. For monorepos, blame can be particularly heavy. Use git blame --progress to see progress. If you find yourself blaming the same file often, consider splitting it into smaller modules. In production, we once had a 15k-line configuration file that took 30 seconds to blame. We reduced it by breaking it into per-environment files.

# Blame only lines 100-200
git blame -L 100,200 hugefile.js
# Blame with progress indicator
git blame --progress hugefile.js
# Blame only commits after a date
git blame --since="2026-01-01" hugefile.js

Blame Across Branches and Forks

By default, blame works on the current branch. To blame a file on a different branch, specify the branch name: git blame other-branch file. This is useful when comparing changes between branches. For forks, you can add the fork as a remote and blame using the remote branch: git blame upstream/main file. However, blame only follows the file's history within the current repository. If the file was copied from another repo, blame won't show the original history unless you use --follow for renames. For cross-repo history, you need to use git log --follow or tools like git blame with -C to detect moved code from other files. In practice, if you're investigating a bug that spans branches, blame the file on the branch where the bug was introduced.

# Blame on a feature branch
git blame feature/login src/auth.js
# Blame on a remote branch
git blame origin/main src/auth.js
# Follow renames
git blame --follow src/auth.js

Automating Blame in CI/CD Pipelines

You can integrate blame into your CI to automatically flag risky changes. For example, if a line is blamed on a commit that is known to be buggy, you can warn. Or, you can use blame to generate a report of who changed what in a release. A common pattern: after a merge, run git blame on critical files and compare with the previous release. Use git diff --name-only to get changed files, then blame each. This can be done in a script. For example, in a GitHub Action, you can run git blame --since="last release tag" to get all changes since the last tag. Be careful with performance: only blame files that changed. Also, consider using git log instead if you only need commit-level info. Blame is line-level, which is more granular but slower.

#!/bin/bash
# Get changed files between two tags
CHANGED_FILES=$(git diff --name-only v1.0 v1.1)
for file in $CHANGED_FILES; do
  echo "=== $file ==="
  git blame --since="2026-01-01" "$file" | head -20
done

Common Pitfalls and Misconceptions

One major pitfall: blame shows the last person who modified the line, not necessarily who wrote it. If a line was refactored by a senior dev, blame points to them, even if the original logic was written by a junior. Another: blame doesn't show deletions. If a line was deleted, you can't blame it. Use git log -S or git log -G to find commits that added or removed specific strings. Also, blame on a binary file is meaningless. Git blame only works on text files. Finally, blame can be misleading in merge commits. If a merge conflict was resolved, the resolution is blamed on the merger, not the original author. Always check if the commit is a merge. Use git show --no-commit-header to see the diff.

# Check if a commit is a merge
git cat-file -p a1b2c3d4 | head -5
# Output shows two parents if merge

Alternatives to Git Blame: When to Use Git Log Instead

Git blame is line-level; git log is commit-level. If you need to find who introduced a specific string, use git log -S "string" (pickaxe) or git log -G "regex". These search commit diffs, not just the current file. For example, git log -S "TODO" --all finds all commits that added or removed the string "TODO". This is more powerful than blame for finding origins. Another alternative: git shortlog summarizes commits per author. For code review, git diff is better. Blame is best for understanding a specific line's last change. If you need to understand the evolution of a function, use git log -L (line log), which shows the history of a line range. This is like blame but over time.

# Find commits that added or removed 'bug'
git log -S "bug" --oneline
# Show history of lines 10-20
git log -L 10,20:src/app.js --oneline