Once in a while it happens that I want to find the commit that introduced a bug. For example, today it happened that one of our integration testing suites was broken, but I didn’t quite know which commit was the culprit.

Git bisect allows you to specify a ‘bad’ commit (a commit that you know is at a point where the bug exists – usually this is the latest commit) and a ‘good’ commit (a commit where you know the bug didn’t exist – usually this is some past revision). Git will basically do a binary search through all the revisions to pinpoint the culprit. Another common use for bisect is in tracking down a broken UI change (since CSS changes are often not tested with automated tests).

After you have the ‘good’ and ‘bad’ commits it’s very easy to narrow it down to the culprit.

git bisect start
git bisect good sha-of-the-good-revision
git bisect bad sha-of-the-bad-revision

Git will now checkout a revision and ask you if the bug exists in this revision. After running your test (manual/automated) you need to tell Git the outcome.

git bisect good/bad

You now repeat this process of marking revisions as good or bad until Git tells you which commit is the culprit. Once you’re done, you can tell Git that you’re finished bisecting.

git bisect reset

This will get you back to your starting point. That’s all there is to it! Happy coding.

Share on: Twitter, Facebook, Google+ or use the Permalink