I linked to a good article about git bisect recently. I’ve now experimented with it on a project and here’s a few extra pieces I found out:

• git bisect log shows you the history of the bisect
• git bisect reset completes the bisect and returns you to HEAD (or whatever commit you specify)
• git bisect visualize shows the bisect status in gitk (I prefer gitx though)
• git bisect run command is awesome. Just pass in the command you use to run your tests and it automates the bisecting eg git bisect run bundle exec rspec spec (you still need to set up the bisect first with git bisect start and specifying the starting good and bad commits)

Git bisect is designed to help you hone in on a commit that introduced a bug. If you use a CI server or simply run all your tests against every commit, you shouldn’t end up needing git bisect unless it is a bug for which you don’t currently have a test. In that case, you’ll most likely write a test that verifies that bug and then commit a fix. No need for git bisect.

An instance where it might be useful is where you need to know exactly at what time a bug was introduced so that you can identify data that was affected and which will need to be adjusted. You can then write a test, leave it as an uncommitted file, then use git bisect to roll back and forwards to find the commit where the bug was introduced. Then you can check when you deployed this commit and begin the process of fixing the affected data.