Git Blame & Archaeology

Also Known As

TL;DR

Explanation

git blame file.php shows the last commit and author for each line — useful for context on why code exists. git log -S 'string' finds commits where the string was added or removed (pickaxe search) — answers 'when was this function added?'. git log --follow -p file traces the history of a file including renames. git bisect binary-searches commit history to find the first bad commit introducing a bug. git annotate is an alias for blame with more context. Combining these tools turns git history into comprehensive documentation.

Common Misconception

Why It Matters

Common Mistakes

• git blame showing a formatting commit — use -w to ignore whitespace changes.
• Not using git bisect for regressions — manually checking 50 commits is hours; bisect finds the culprit in 6 steps.
• Assuming the blamed commit explains everything — the PR or issue linked from the commit message has more context.
• Not using git log --follow for renamed files — plain git log stops at the rename.

Code Examples

# Manual regression hunt — slow:
# Bug appeared 'sometime in the last month'
# Check commit from 30 days ago: bug present? No
# Check commit from 20 days ago: present? No
# Check commit from 10 days ago: present? Yes
# ...
# 2 hours later: found the commit

# git bisect — binary search, 6 steps for 64 commits:
git bisect start
git bisect bad HEAD          # Current commit has the bug
git bisect good v1.5.0       # This tag was fine
# git checks out the middle commit:
git bisect good              # No bug here — move to upper half
git bisect bad               # Bug here — narrow further
# ... 4 more steps
# Result: 'abc1234 is the first bad commit'
git bisect reset

# Find when a function was added:
git log -S 'processPayment' --oneline
# Show full history of a file:
git log --follow -p -- src/Payment/Gateway.php

References

• ↗ https://git-scm.com/docs/git-bisect

Tags

Related Terms