If you have ever had a situation where a commit was made that had a bug – but you are not sure which commit it is – then git-bisect is the tool you need.
To use git-bisect, you need to know a good commit and a bad commit. It does not matter how recent the good commit is – as long as it is free of the bug in question. So if you think the bug was introduced in the last 2 weeks, choose the good commit from two weeks ago. Usually the bad commit is the current commit.
The bisect process is started with three commands: 1 to start the bisect operation, 1 to indicate a good commit, and 1 to indicate a bad commit.
This process is repeated with git successively cutting the commits in half and you responding with git bisect good or bad. When the offending commit is found, git will indicate that the operation is complete.
To stop the bisect, type ‘git-bisect reset’.
The below example is small but it illustrates how bisect works. The binary nature of this search means that even a repository with thousands of commits can be searched relatively quickly.
In steps 1, 2, and 3, I indicate if the checked out commit contains the bug (bad) or not (good). In step 4, git has identified the offending commit and lists the commit details (who to blame…).