Skip to main content

Detecting Regression Commits Using git bisect

· 2 min read

Locating the commit that introduced a regression, or some undesirable change, in a codebase can be difficult. Locating the same in a frequently-changing codebase with a large number of contributors is harder again.

Fortunately git bisect provides a helpful tool for doing precisely this. Rather than performing a linear search of the commits, git bisect uses a clever binary search algorithm to locate the offending commit far more efficiently.

Git Bisect VisualisationGoodBadBadFirst badcommitGood1234567891011

Having identified a commit from the past where the regression did not exist (e.g. git checkout a commit from say a month ago), my typical usage of git bisect is along the lines of:

  1. Check out the branch containing the regression and run git bisect start.
  2. Label the good and bad commits: git bisect good <commit hash> and git bisect bad <commit hash>. The current commit is taken if the commit hash argument is omitted.
  3. Bisecting commences — a candidate commit is automatically checked out and the number of revisions left to test and number of remaining steps are printed. You can run git bisect reset to abort at any stage.
  4. Check whether the regression still exists, whether this involves running an automated test or taking manual replication steps. If the candidate commit contains the regression, run git bisect bad, otherwise run git bisect good. If any search area remains, another candidate commit is automatically checked out.
  5. Repeat #4 until the bisecting process concludes and the bad commit's hash is listed.

Given git bisect's binary search technique, the number of steps required will only increase logarithmically as the number of commits increases — this is a time-saving tool that I turn to again and again.