Phase 5: Debugging Methodology · ~35 minutes · git · git bisect

Binary Search Debugging

25 real commits, one planted bug, found in exactly 4 steps by git bisect — not by checking all 25 one at a time. The same halving idea from Course 01's binary search, applied to a commit history instead of a sorted list.

Hiring signal: Reaches for git bisect on a real regression instead of manually checking commits one at a time from the beginning

What you will learn

Explain bisecting a search space as the same halving idea as binary search, applied to debugging
Use git bisect to find the exact commit that introduced a regression
Explain why checking commits sequentially from the start is slower than bisecting
Predict how many bisection steps a given commit range needs

Introduction

Type: Learn Languages: git Prerequisites: Lesson 03 (Systematic (Scientific) Debugging) Time: ~35 minutes

Objective

Learning objectives

Explain bisecting a search space as the same halving idea as binary search, applied to debugging
Use git bisect to find the exact commit that introduced a regression
Explain why checking commits sequentially from the start is slower than bisecting
Predict how many bisection steps a given commit range needs

What you're building

Create a real repository with at least 20 commits, planting a genuine, detectable bug at a commit somewhere in the middle (not deliberately at the exact midpoint — pick a position that isn't suspiciously convenient)
Write a small check script that returns success/failure based on whether the bug is present (following this lesson's bisect_check.sh pattern)
Run a real git bisect start/good/bad/run session and let it find the exact bad commit automatically
Write bisect_results.txt recording the real number of steps it took, the exact commit it identified, and a comparison to how many commits sequential checking would have needed in the worst case

A regression exists somewhere in a range of 50 commits. Roughly how many bisection steps should git bisect need, at most?

2^6 = 64, which is the first power of 2 at or above 50 — so about 6 steps suffice, matching this lesson's log2(N) relationship (25 commits needed about 5 steps in the real example above; 50, roughly double, needs only about one more step, not double the steps). Critically, this count barely depends on WHERE in the 50-commit range the actual bad commit sits — unlike sequential checking, whose cost is entirely dependent on the bad commit's position, bisection's cost stays close to log2(N) regardless.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Problem, Check Yourself, Key Terms & Next — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.