We're sorry but this app doesn't work properly without JavaScript enabled. Please enable it to continue.

This lesson's interactive features are locked, please to keep using them

Bisect

Click to play video

So we know how to fix problems in our code. We can either:

  1. Revert the commit with the bug (this is more common on large teams)
  2. "Fail forward" by just writing a new commit that fixes the bug (this is more common on small teams)

But there's another question:

How do we find out when a bug was introduced?

That's where the git bisect command comes in. Instead of manually checking all the commits (O(n) for Big O nerds), git bisect allows us to do a binary search (O(log n) for Big O nerds) to find the commit that introduced the bug.

For example, if you have 100 commits that might contain the bug, with git bisect you only need to check 7 commits to find the one that introduced the bug.

commits to check max checks to find
1 1
---------------- --------------------
2 1
---------------- --------------------
10 4
---------------- --------------------
100 7
---------------- --------------------
1000 10
---------------- --------------------
10000 14

git bisect isn't just for bugs, it can be used to find the commit that introduced any change, but issues like bugs and performance regressions are a common use case.