All chapters in this track
- 011. The Mental Model
- 022. Essential Setup
- 033. Core Daily Workflow
- 044. Branching
- 055. Merging & Conflict Resolution
- 066. Rebasing
- 077. Remote Repositories
- 088. Stashing
- 099. Undoing Things
- 1010. Tagging & Versioning
- 1111. Cherry-Pick
- 1212. Git Bisect & Blame
- 1313. Git Hooks
- 1414. Submodules
- 1515. Team Workflows
- 1616. Power Commands & Aliases
- 1717. Reflog: The Safety Net
- 1818. Practice Tasks
- 19Quick Reference Cheatsheet
Chapter 12 of 19
12. Git Bisect & Blame
Bisect — find which commit introduced a bug
Binary search through history. Cuts O(n) searches to O(log n).
git bisect start
git bisect bad # current commit is broken
git bisect good v1.2.0 # this tag was working
# Git checks out the midpoint commit
# Test your code, then:
git bisect good # if this commit works
git bisect bad # if this commit is broken
# Git narrows down until it prints:
# a1b2c3 is the first bad commit
git bisect reset # return to HEAD when done
# Automate with a test script
git bisect run python test.py # 0 = good, non-zero = bad
Blame — see who last changed each line
git blame file.py # every line: commit + author + date
git blame -L 20,40 file.py # limit to lines 20–40
git blame -w file.py # ignore whitespace changes
git log -S "function_name" -- file # find commit that added/removed a string
git log -G "regex" # search with regex
Tip: git blame is not about guilt — it's about understanding why code was written. Use git show <commit> after blame to read the full context.