The least-used but most-powerful debugging tool for engineers

One of the least known and most powerful tools in a developer’s arsenal is git bisect

The git bisect command utilizes my favorite algorithm, the binary search, so maybe I’m just a bit biased, but in reality, this seldom used powerful debugging tool is one I relish every time I use it.

Let’s paint a scenario. You and your team have been plugging away on an app for a client for the last 18 months. You’ve now amassed several thousand commits and pull requests. The client reaches out and points out a defect. And you have no idea where that defect originated. You know that you fixed this back in December, but now it is rearing its ugly head again.

Enter git bisect.

With git bisect, you specify a commit HEAD (using the first few characters of any commit) that you know has the defect (like the latest commit) and an older commit that you know did NOT (like back in December in our example).

Git will then calculate the number of commits between these two times. Perhaps there are 1000 commits between the “good” commit and the “bad” commit. Git will then checkout the one closest to the middle of these, performing a binary search. It will then ask you to test that commit and see if the defect exists.

If the defect exits, it then goes back halfway towards the “good” commit, checks out the closest commit, and asks again if this commit is good or bad.

If the defect doesn’t exits, it goes halfway in the other direction.

Within 5–10 jumps, you land on the exact commit where the defect occurred. This makes debugging the issue 1000 times easier!