In this section, we will learn how we can use git bisect
to find the commit that introduced a bug into our repository.
Using a binary search, git bisect
can help us detect specific events in our code. For example, you could use bisect to locate the commit where:
- a bug was introduced.
- a new feature was added.
- a benchmark’s performance improved.
git bisect
works by cutting the history between two points in half and then checking you out to that commit. You then check whether the bug/feature exists at that point and tell Git the result. From there, Git will do another division, etc until you have located the desired commit.
When you are doing a bisect, you are essentially in a detached head state. It is important to remember to end the bisect with
git bisect reset
before attempting to perform other operations with Git.
- Initiate the binary search:
git bisect start
. - Specify the commit where you noticed the code was broken:
git bisect bad <SHA>
. - Specify the commit where you knew things were working:
git bisect good <SHA>
. - Bisect will check you out to the midpoint between good and bad.
- Run a test to see if the game would work at this point. Our test is to use
ls
to see if anindex.html
file exists. - If the game is still broken (there is no
index.html
file), type:git bisect bad
. - If the game works (and there is an
index.html
file), type:git bisect good
. - Git will bisect again and wait for you to test. This will happen until Git has enough information to pinpoint the first bad commit.
- When Git has detected the error, it will provide a message that
SHA is the first bad commit.
- Exit the bisect process:
git bisect reset
.
Bisect can also run the tests on your code automatically. Let's try it again using a shortcut command and a test:
git bisect start <bad-SHA> <good-SHA>
git bisect run ls index.html
git bisect reset