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.

Git Bisect Simulator | DevTools Surf

DevTools Surf

Example: Git Bisect Simulator

A worked example, rendered from real sample data. Sign in to run the tool on your own input.

Input

good=v2.3.0
bad=v2.4.0-rc1
commits=84
test=npm test -- payment
test_seconds=45

Output

═══ What this tool did ═══
✗ No repository was read, no commit was checked out and no test was run. There are no commit hashes, dates or messages here that you did not supply. This page runs entirely on the server that rendered it and makes no outbound network calls.
✓ What it computes is the bisect arithmetic: how many tests the search needs, which commit git picks at each step, and how the range narrows. That is deterministic — binary search has no randomness in it.
ℹ No git log was pasted, so the plan below uses 84 as the number of commits in v2.3.0..v2.4.0-rc1.

═══ How long the search takes ═══
Commits in v2.3.0..v2.4.0-rc1: 84
Tests needed: 7 (⌈log₂(84 + 1)⌉) — git prints this as "roughly 7 steps".
Linear search would need up to 84. Bisect turns 84 tests into 7: that is the entire point of it.
Doubling the range to 168 commits costs exactly one more test.
At 45s per test run, the search takes about 5m 15s of machine time.

═══ Session ═══
  git bisect start
  git bisect bad v2.4.0-rc1
  git bisect good v2.3.0
  # git checks out commit #42 from v2.4.0-rc1 — roughly 7 steps, 84 revisions left to test after this
  npm test -- payment && git bisect good || git bisect bad
  # …repeat until git prints "<sha> is the first bad commit"
  git bisect reset

═══ Verdict ═══
✗ Which commit introduced the regression cannot be determined here. It is a property of your code and only running your test at each of the commits above can decide it.
• Add `first_bad=<sha>` (or `first_bad=<n>` for the nth commit) and this tool will replay the exact session for you.

═══ How git picks the co
…

About Git Bisect Simulator

Git Bisect Simulator preview - Developer Utilities tool

Work out how many tests a bisect needs, which commit git picks at each step, and replay the session over your own git log. 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.

Related Developer Utilities Tools

Collection JSON → cURL Git Diff → HTML Regex Visualizer Makefile Explainer Shell Script Linter GitHub Actions Visualizer HAR File Viewer API Response Mocker