git bisect

The Hook (The "Byte-Sized" Intro)

1,000 commits between the last known-good version and the current broken one. Testing each one would take days. git bisect does it in ~10 steps using binary search. Mark one commit as good, one as bad, and Git checks out the midpoint. You test it — good or bad? Git halves the range again. In log₂(1000) ≈ 10 steps, you find the exact breaking commit. Guaranteed.

📖 What is git bisect?

git bisect performs a binary search through commit history to find the first commit that introduced a bug. You provide a known good and a known bad commit, and Git navigates the search automatically.

Conceptual Clarity

The bisect process:

Step	Action	Commits Remaining
1	Mark bad: HEAD	1000
2	Mark good: v1.0	1000
3	Git checks out middle	500
4	You test: "good"	250
5	Git checks out new middle	250
6	You test: "bad"	125
...	Continue halving	...
10	Found the breaking commit	1

Bisect commands:

Command	What It Does
`git bisect start`	Begin bisecting
`git bisect bad`	Mark current commit as bad
`git bisect good <ref>`	Mark a commit as good
`git bisect skip`	Skip untestable commit
`git bisect reset`	End bisect, return to original branch
`git bisect run <script>`	Automate with a test script

Real-Life Analogy

It's the number-guessing game: "I'm thinking of a number between 1 and 1000." You always guess the middle: "500?" → "Too high." → "250?" → "Too low." → "375?" In 10 guesses, you find it. git bisect plays this game with commits.

Visual Architecture

flowchart LR GOOD["✅ Good: v1.0"] --> MID["🔍 Midpoint"] MID --> TEST{"Test result?"} TEST -->|"Good"| RIGHT["Search right half"] TEST -->|"Bad"| LEFT["Search left half"] LEFT --> MID2["🔍 New midpoint"] RIGHT --> MID3["🔍 New midpoint"] style GOOD fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb style MID fill:#1a1a2e,stroke:#ffd700,color:#ffd700

Why It Matters

Logarithmic speed: 1000 commits → ~10 tests. 1,000,000 → ~20 tests.
Guaranteed result: If the bug is reproducible, bisect will find it.
Automatable: bisect run can execute tests automatically.
No knowledge needed: You don't need to understand the code — just test good/bad.

Code

bash

# ─── Manual bisect ───
git bisect start
git bisect bad                 # Current HEAD is broken
git bisect good v1.0.0         # v1.0.0 was working
# Git checks out a midpoint commit
# Test it manually...
git bisect good                # This commit is fine
# Git checks out a new midpoint...
git bisect bad                 # This one is broken
# Continue until:
# abc1234 is the first bad commit

git bisect reset               # Return to original branch

# ─── Automated bisect ───
git bisect start HEAD v1.0.0
git bisect run npm test
# Git runs the test at each midpoint automatically!
# exit 0 = good, exit 1 = bad, exit 125 = skip

# ─── Skip untestable commits ───
git bisect skip
# Skips a commit that can't be tested (e.g., won't compile)

# ─── View bisect log ───
git bisect log
# Shows the path of good/bad decisions

Key Takeaways

git bisect uses binary search — O(log n) complexity.
Automate it: git bisect run <test-script> for hands-free bug finding.
Use skip for commits that can't be tested (build failures, etc.).
Always git bisect reset when done to return to your branch.

Interview Prep

Q: How does git bisect work? A: Binary search through commit history. You mark a known-good and known-bad commit. Git checks out the midpoint for you to test. Based on your result (good/bad), it halves the search range again. This repeats until the first bad commit is found in O(log n) steps.
Q: How do you automate git bisect? A: git bisect start HEAD <good-commit> then git bisect run <script>. The script must return exit code 0 for good, non-zero for bad, and 125 for skip. Git runs the script at each midpoint automatically.
Q: What do you do if a midpoint commit won't compile? A: Use git bisect skip. Git will try a nearby commit instead. This may slightly reduce precision but keeps the search progressing.