Softwares have bugs and sometimes they can live for a long time before being discovered. That means that from the point in time when the bug was introduced to the point when it is discovered a lot of time might have passed and many code modifications may have been done.
The problem then is to find when the bug was introduced or more precisely what code change inserted the bug.
The best way to find that out is to do a binary search (also called half-interval search, cf http://en.wikipedia.org/wiki/Binary_search) on your code. You know which version of your software was working and you know that the current version is not working. Then the strategy is to put your code in the state it was at the middle point in between those 2 commits. Then you test again to see if it works. If it does then you take the range from that point up to the current working version. If it doesn't then you take the other half-interval. In each case you will then repeat the operation until you reach the point where you have found the guilty commit.
This strategy works very well but is really time consuming and involves lots of manual work.
The git bisect command was created exactly to tackle those shortcommings by automating most of the work. In order to start bisecting your code to find a bug with git just do:
git bisect start <bad commit> <good commit>After what git will automatically checkout the half-interval commit and ask you if this version is correct. Depending on your answer it will then follow by halving the selected range and ask you again about the goodness of the current version.
This is already a huge improvment and really helps you out when you are hunting a difficult bug.
But there is even more. Let's pretend a bug has been reported, you have been able to reproduce it and you have created a test case casting light on it. Now you are ready to use git bisect run which takes as parameter a command to run at each bisection step. Depending on the output of the command (0 everything is fine, otherwise the bug is still here) git will automatically choose the correct half-interval and continue running the bisection.
And now you have it: a full bug hunting system. Just write a test showing the bug and git will take care of finding for you the commit that introduced this bug in a very short time (or at least with minimun manual effort from your part).
As usual with git you can consult the excellent documentation (git help bisect) giving you all options available and information you might need as well as examples.