Bisect narrows a regression between known good and bad revisions using repeated checks. Reliable classification matters more than speed.
Before you start
You should understand commits, branches, the working tree and the staging area. Draw the commit graph before changing history. Try commands in a disposable repository with a clean working tree so you can observe exactly which references and files each operation changes.
The practical goal is to reason through this situation: A deterministic script marks each candidate revision good or bad. Read the walkthrough first, then try the interview exercise before opening its answer. The important part is explaining the decision and its consequences, rather than remembering a definition alone.
Step-by-step walkthrough
Step 1: Establish endpoints
Choose demonstrably good and bad revisions for the same symptom.
Step 2: Create deterministic classification
Use a focused check with reproducible environment requirements.
Step 3: Handle unclassifiable revisions
Skip broken build states rather than guessing good or bad.
Worked scenario
A deterministic script marks each candidate revision good or bad.
An intermittent test fails only one time in ten. Using one run per bisect candidate can misclassify a bad revision as good and lead to a false culprit. Reduce the symptom to a stable reproducer or use justified repeated evidence; report uncertainty where classification remains unreliable.
Common mistake
Flaky tests can send the search toward the wrong commit.
Verify the behavior
Run the classifier repeatedly at known endpoints before starting the search.
Interview exercise
Prepare a useful bisect check.
Answer and reasoning
Use a minimal reproducible symptom, isolate environment differences and skip revisions that cannot be classified honestly.
Continue learning
Compare the scenario with the Git and CI/CD interview questions and test your understanding with the Git and CI/CD MCQs. For terminology and implementation details, consult the reference material.