Simulate binary search through commit history to find regression-causing commits. Part of the DevTools Surf developer suite. Browse more tools in the Developer Utilities collection.
Use Cases
Learn how to narrow down a regression to a specific commit without checking out every intermediate version.
Practice the bisect workflow before using it on a large production repository with a tricky bug.
Demonstrate binary search debugging to junior developers in a risk-free environment.
Plan the bisect strategy for a long-running test suite where each round takes minutes.
Tips
Start bisect with the oldest known-good commit and the newest known-bad commit to minimize the number of steps.
Mark commits as good/bad based on a single reproducible test — inconsistent marking produces wrong results.
Use 'git bisect run <script>' in real git to automate the bisect using a test script that exits 0 for good and non-zero for bad.
Fun Facts
Git bisect was introduced by Linus Torvalds in 2005, the same year he created git itself. The feature performs a binary search through commit history.
Binary search finds a regression in O(log n) steps — in a repo with 1,000 commits between good and bad, bisect needs at most 10 manual test rounds.
Git's internal bisect algorithm uses a shortest-path approach to select the commit that divides the remaining suspect commits most evenly, not necessarily a strict midpoint.
FAQ
How many steps will bisect take?
ceil(log2(N)) steps, where N is the number of commits between good and bad. 100 commits = 7 steps; 1000 commits = 10 steps.
What if I mark a commit incorrectly?
Run 'git bisect reset' to abandon and restart. In the simulator, use the undo button. Incorrect marking produces a wrong answer with no error — always verify your test.
Can I skip commits I can't test?
Yes — 'git bisect skip' tells git to avoid that commit. Git picks the next best candidate. Too many skips in a row cause git to report multiple possible culprits.
