Chapter 41: Bisecting/Finding faulty commits

Section 41.1: Binary search (git bisect)

To find the commit that introduced a bug using a binary search, you can use git bisect. Follow these steps:

Start the git bisect session:

$ git bisect start

Specify a commit where the bug doesn’t exist (a good commit):

$ git bisect good 49c747d

Specify a commit where the bug exists (generally, HEAD):

$ git bisect bad HEAD

Git will perform a binary search by switching to an intermediate revision. Inspect the code to determine if the revision is good or bad. If it’s good, use:

$ git bisect good

If the revision contains the bug, use:

$ git bisect bad

Repeat the process as instructed by Git. Git will present a single revision representing the commit where the bug was introduced.

After finding the faulty commit, end the bisect session and return to HEAD:

$ git bisect reset

If you have a script that can check for the bug, you can automate the process using:

$ git bisect run [script] [arguments]

Where [script] is the path to your script and [arguments] are any arguments to be passed to the script. The script’s exit code determines if the revision is good or bad.

Section 41.2: Semi-automatically find a faulty commit

If you know that a regression was introduced between the master branch and a previous release (e.g., tagged or with a known commit hash), you can use git bisect with a binary search approach:

Start the bisecting process:

git bisect start master old-rel

Specify that master is a broken revision and old-rel is the last known version.

Git will check out a detached head in the middle of both commits. Test if it works and use either:

git bisect good

or

git bisect bad

based on the result. If a commit cannot be tested, use git reset to try the next one.

After a few steps, Git will output the faulty commit hash.

To abort the bisect process, use:

git bisect reset

Git will restore the previous state.