Bisect for finding bug-introducing commits in Git - Step-by-Step Execution

Process Flow - Bisect for finding bug-introducing commits

Start Bisect

↓

Mark Good Commit

↓

Mark Bad Commit

↓

Git Chooses Mid Commit

↓

Test Mid Commit

↓

Good

↓

Mark Good

↓

Repeat Until One Commit Left

↓

Found Bug-Introducing Commit

↓

End Bisect

The bisect process narrows down the commit range by marking commits as good or bad, testing the middle commit each time, until it finds the exact commit that introduced the bug.

Execution Sample

Git

git bisect start
git bisect good v1.0
git bisect bad v2.0
# test commit chosen by git
# mark good or bad
# repeat until found

This sequence starts bisect, marks known good and bad commits, then tests commits in between to find the bug-introducing commit.

Process Table

Step	Action	Commit Tested	Result	Next Step
1	Start bisect	-	Bisect started	Mark good commit
2	Mark good commit	v1.0	Marked as good	Mark bad commit
3	Mark bad commit	v2.0	Marked as bad	Git picks middle commit
4	Test middle commit	v1.5	Bug present	Mark bad commit
5	Mark bad commit	v1.5	Marked as bad	Git picks new middle commit
6	Test middle commit	v1.25	Bug absent	Mark good commit
7	Mark good commit	v1.25	Marked as good	Git picks new middle commit
8	Test middle commit	v1.375	Bug present	Mark bad commit
9	Mark bad commit	v1.375	Marked as bad	Git picks new middle commit
10	Test middle commit	v1.3125	Bug absent	Mark good commit
11	Mark good commit	v1.3125	Marked as good	Git picks new middle commit
12	Test middle commit	v1.34375	Bug present	Mark bad commit
13	Mark bad commit	v1.34375	Marked as bad	One commit left
14	Bisect complete	v1.34375	Bug introduced here	End bisect

💡 Bisect ends when only one commit remains between good and bad, identifying the bug-introducing commit.

Status Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5	After 6	After 7	Final
Good Commit	-	v1.0	v1.0	v1.25	v1.25	v1.3125	v1.3125	v1.34375	v1.34375
Bad Commit	-	v2.0	v1.5	v1.5	v1.375	v1.375	v1.34375	v1.34375	v1.34375
Current Tested Commit	-	v1.5	v1.25	v1.375	v1.3125	v1.34375	-	-	-
Bisect State	Not started	Started	In progress	In progress	In progress	In progress	In progress	Complete	Complete

Key Moments - 3 Insights

Why does git pick the middle commit between good and bad commits?

Git uses a binary search approach to quickly narrow down the commit range by testing the middle commit, as shown in steps 4, 6, 8, 10, 12 in the execution_table.

What happens if the tested commit is good?

If the tested commit is good, it becomes the new 'good' commit, narrowing the search range, as seen in steps 6, 10, and 11.

When does bisect end?

Bisect ends when only one commit remains between the good and bad commits, identifying the bug-introducing commit, as in step 14.

Visual Quiz - 3 Questions

Look at the execution_table at step 4. What was the result of testing commit v1.5?

A Bug present

B Bug absent

C Commit marked good

D Bisect ended

💡 Hint

Check the 'Result' column for step 4 in the execution_table.

At which step does the bisect process mark commit v1.25 as good?

A Step 5

B Step 6

C Step 7

D Step 8

💡 Hint

Look for 'Mark good commit' action with commit v1.25 in the execution_table.

If the commit tested at step 8 was good instead of bad, how would the next tested commit change?

A Git would pick a commit between v1.25 and v1.375

B Git would pick a commit between v1.375 and v1.5

C Git would pick a commit between v1.0 and v1.25

D Bisect would end immediately

💡 Hint

Refer to the binary search logic in the concept_flow and variable_tracker.

Concept Snapshot

git bisect start
Mark a known good commit: git bisect good <commit>
Mark a known bad commit: git bisect bad <commit>
Git tests middle commits between good and bad
Mark tested commits as good or bad
Repeat until one commit remains
This commit introduced the bug

Full Transcript

Git bisect helps find the commit that introduced a bug by using a binary search. You start bisect, mark a known good commit where the bug was absent, and a known bad commit where the bug is present. Git then picks the middle commit to test. If the bug is present, mark it bad; if absent, mark it good. This narrows the search range. Repeat testing and marking commits until only one commit remains between good and bad. This commit is the one that introduced the bug. The process is efficient because it halves the search space each time.