Have you ever experienced a bug report where you think to yourself, "I know I fixed that like two months ago!" but you're not sure how it broke? That's where git bisect comes in. It's a really nifty tool that's built into Git that allows you to quickly find the commit that introduced the regression because sometimes finding the regression can be like finding a needle in a haystack.
How it works is pretty simple: you start the process with `git bisect start` and then mark a commit that you know is bad with `git bisect bad`. You then checkout a past commit you know wasn't broken and mark is with `git bisect good`. From there, Git checks out the next commit between the last bad one, where you can test the regression and see if it's present. You then mark that commit as good or bad. Rinse and repeat until you find the commit that introduced the bug.
From there you can chat with your teammates if you have any or quickly fix the bug.
In this screencast tutorial, I walk through the steps of using Git Bisect to find and fix a bug in my website's code.
I've found git bisect to be particularly useful when fixing time-sensitive bugs, like when an "oh crap" bug goes out to Production and bug reports are coming in through Support. Start bisecting, find the issue, fix it, and then take a break to relax after the pressure of fixing the time-sensitive bug.
Branch on GitHub with the code: https://github.com/brettchalupa/brett...
Associated blog post: https://code.brettchalupa.com/quickly...
Curious to learn more about git bisect? The docs are fantastic: https://git-scm.com/docs/git-bisect
There's also the ability to run an automated script with `git bisect run` to pinpoint the issue, which I'll cover in another episode!