Finding a bad commit with git bisect

"It worked last week, and now it doesn't." Somewhere in dozens or hundreds of commits, one introduced the bug. Reading them all is hopeless — but you don't have to. git bisect finds the culprit with a binary search, the same bisection move from the debugging lesson, applied to history.

The idea

You tell git one commit where the bug was absent (good) and one where it's present (bad). Git checks out a commit halfway between them and asks: good or bad? Your answer eliminates half the remaining commits. Repeat, and a range of 1,000 commits collapses to about ten checks.

A bisect session

git bisect start
git bisect bad                 # the current commit is broken
git bisect good a1b2c3d        # this older commit worked

# git checks out a commit in the middle. Test it, then tell git:
git bisect good                # ...if the bug is absent here
git bisect bad                 # ...if the bug is present here

# repeat until git names the first bad commit, then:
git bisect reset               # return to where you started

At the end git prints the exact commit that introduced the bug — its hash, message, and author. Now you read just that small diff to understand the cause.

Automate it

If you can write a command that exits 0 when good and non-zero when bad (often a test), git will run the whole search for you:

git bisect start HEAD a1b2c3d
git bisect run npm test

Where to go next

That completes the Git in practice module — you can merge, rebase, resolve conflicts, undo anything, move work around, review changes, and hunt regressions entirely by hand. Next, the Documentation modules: reading docs well, and writing docs that last.