#gitbisect

Imagine the scenario where your code has been reported for a bug and you don't know exactly which part for your commit history induced this particular bug. But you sure know a past commit where this bug never existed (let's call it "good commit") and there are around 100 commits in between the "good commit" and your current commit(which we can call as "bad commit").

So you are in a situation where you want to review all the 100 commits in between the "good commit" and the "bad commit". Not a plausible solution, is it?

So what's the way to avoid "searching" all 100 commits to find the buggy code. You got it right. Yes, do a binary search. Since we are lazy, we don't want to binary search 100 commits which will take us log2(100) = 7 (approx.) steps to find the buggy branch. Luckily we have a life saver tool called bisect tool from git. Let us see how it works.

In your current branch, you have to do

git bisect start

This command simple starts the bisect tool.Then you have to mark the bad commit as bad. We can do that using

git bisect bad

Then we have to tell the bisect tool about the good branch. You can give the commit hash of the good commit. You can obtain the commit hash using 

git log

and then

git bisect good [good commit hash]

Now you will be surprised to see that the bisect tool takes you to the center commit of the good and the bad commit. At this point, you can run your test and see if the bug that was reported exists. If it doesn't, then you can mark the commit as good using

git bisect good

else you can mark it as bad using

git bisect bad

So this takes you to the left or the right of the current commit you are on. This looks so simple, ain't it?

Finally at the end don't forget to stop the bisect tool using

git bisect reset

this will reset your HEAD pointer to where you were before you started, else you will end up in a wierd state.

Reference:

Thoughtbot Blog post on git bisect

git-scm reference