Git Bisect
Also Known As
git binary search
bisect
TL;DR
A binary search tool that finds the commit that introduced a bug by marking commits as good or bad — locating the culprit in O(log n) steps.
Explanation
git bisect automates a binary search through commit history. You mark a known-good commit and a known-bad commit, then git checks out the midpoint. You test and mark it good or bad, halving the search space each time. For 1000 commits, this finds the culprit in ~10 steps. With git bisect run, you automate the test — bisect runs your test suite and marks commits automatically, making regression hunting fully automated.
Diagram
flowchart TD
START[git bisect start] --> BAD[git bisect bad HEAD<br/>current commit has bug]
BAD --> GOOD[git bisect good v1.0<br/>this tag was fine]
GOOD --> MID[Git checks out midpoint]
MID --> TEST{Test: bug present?}
TEST -->|yes - git bisect bad| NARROW1[Narrow to upper half]
TEST -->|no - git bisect good| NARROW2[Narrow to lower half]
NARROW1 & NARROW2 --> MID
MID -->|after log2 N steps| FOUND[First bad commit identified]
FOUND --> RESET[git bisect reset]
INFO[64 commits = 6 steps<br/>1000 commits = 10 steps]
style FOUND fill:#238636,color:#fff
style INFO fill:#1f6feb,color:#fff
Common Misconception
✗ You need to know programming history to use git bisect — you only need a reproducible test; git bisect run handles the rest automatically.
Why It Matters
Without bisect, finding a regression in 500 commits requires manual investigation; bisect finds it in 9 steps — transforming hours of debugging into minutes.
Common Mistakes
- Not having a reproducible test before starting bisect — manual marking requires re-testing at each step.
- Marking a commit as bad when it has an unrelated test failure — poisons the search.
- Not running git bisect reset after finishing — leaves the repo in detached HEAD state.
- Not using git bisect run with an automated test — missing the most powerful feature.
Code Examples
✗ Vulnerable
# Manual bisect — slow without automation:
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
# Git checks out commit — developer manually runs app and marks
git bisect bad # or good
# Repeat 10 times manually...
✓ Fixed
# Automated bisect with test script:
git bisect start
git bisect bad HEAD
git bisect good v1.2.0
# test.sh exits 0 = good, non-zero = bad:
git bisect run ./test.sh
# Git runs binary search automatically — finds the commit
git bisect reset # Return to original HEAD
References
Tags
🤝 Adopt this term
£79/year · your link shown here
Added
15 Mar 2026
Edited
22 Mar 2026
Views
35
🤖 AI Guestbook educational data only
|
|
Last 30 days
Agents 0
No pings yet today
No pings yesterday
Amazonbot 15
Perplexity 8
Ahrefs 3
SEMrush 2
Google 2
Majestic 1
Also referenced
How they use it
crawler 30
crawler_json 1
Related categories
⚡
DEV INTEL
Tools & Severity
🔵 Info
⚙ Fix effort: Low
⚡ Quick Fix
Run git bisect start, mark the current broken commit as bad and a known good commit as good, then git bisect run vendor/bin/phpunit to automate finding the regression
📦 Applies To
git 1.7.14
any
🔗 Prerequisites
🔍 Detection Hints
Bug regression that appeared at some unknown point in history; manually reviewing commits to find cause
Auto-detectable:
✓ Yes
git
phpunit
pest
⚠ Related Problems
🤖 AI Agent
Confidence: Low
False Positives: High
✗ Manual fix
Fix: Low
Context: File