Git Bisect – The Developers Wet Dream – Binary Bug Search
Jeremy Olliver and I used git-bisect for the first time yesterday. We had a bug in our rails code which was preventing an ajax call to work properly. We had both spent a few hours to find the bug but with no luck had to divert traffic from that page.
It was daunting as we had no idea how the problem was being created. A week later, as we had more time to spare on the problem, we sat down again to tackle it. It was time to fix this once and for all.
We started looking on Google ways we could go back in time to find the commit that caused the bug. As if Google was working on the problem for us it showed us Git-Bisect with an inciting description below the title. After a moment of comprehending it, we quickly read up on the topic and push ahead with little expectation of it working. Voodoo magic.
10 minutes later we were sitting at the bad commit. Quick review of the commit, found the problem, 2 minutes later the fix was on production. How did it work?
First you create a branch (for safety sakes). Then follow below
git bisect good <commit identify of the last none good commit, before any problems showed up>
git bisect bad master #this current commit is bad
#now git will run away, shuffle the commits, sprinkle voodoo magic and return.
#Run a test, run the code, whatever, just find out if your problem is still a problem.
#if problem still exists
git bisect bad
#otherwise
git bisect good
#after that, more voodoo and you repeat.
#you will jump about the commits as git tries to narrow down the problem. Once found you will be sitting at the commit before the problem and you can inspect that commit
