Had a client email me recently, mildly concerned, as an update to WP eCommerce broken his search layout. I told him that I couldn’t think of anything between the latest version and the prior version that would have caused any such thing, but I’d be more than happy to check it out.
Initially, if I’m being quite honest, I just assumed it was user error. It’s easy to mis-configure things, set up a theme wrong, etc. Any number of things can go wrong. But, I dug in and in fact, we had broken it. I didn’t recall any changes in the 913 commits between the two changes.
With nothing obvious, and 913 commits between release – what was a developer to do? Enter,
Git bisect is amazing. Prior to using it, you might think to yourself,
“Hmm, self, I suppose I can checkout a few different commits, figure out a commit where it works, and one where it doesn’t, and sort of narrow down a range until I find it.”
And that would be a really good thought. But it would take you, a human, waaaaaaay longer than git would take. That very thought you had? That’s what git bisect does. Imagine you have the master branch, latest commit checked out. You know that a previous version branch worked fine. Check this out.
git bisect start git bisect good git bisect bad branch-188.8.131.52
And boom, you’ve started down the path. Git will analyze how many revisions exist between good and bad, split the difference, and checkout that commit. Then, test to see if the bug still exists. If it does,
git bisect bad. If not,
git bisect good. It will keep narrowing down the commits until it finds the precise commit that caused the issue.
In case you remain unconvinced – remember – I was able to wade through 913 commits to find the single commit that caused a bug in a piece of software that spans hundreds of files and over 150,000 lines of code.
It took about three minutes.
Git bisect is amazing.