git bisect is a binary search which could help you find a commit that introduced a bug. If you don’t have anything to try git bisect on, feel free to clone the simple demo .
Binary search is helpful when you find out you have created a bug along the way, but you don’t know when it appeared and you want to find out what changed to create this bug at first place. In short, binary search means searching a sorted array by repeatedly diving the search interval in half. Simply said, if the bug was created within the last 6 commits and you run git bisect on these, the search will be split into halves until it tracks the commit in which the bug was created.
Lets work on the example, it only has 8 commits which would make it easy to search, but in real life, you could have a bug which appeared long ago – over hundreds of commits, manual searching is not an easy option and binary search is really the best way go.
The bug in our demo is the title on the page which says “It’s awsome”, so if you look closely you are going to notice that we are missing a letter to be the word “awEsome”
Start by listing all commits and try to find a good commit. git log --oneline to get the list of all commits.
Let’s use 0695d06 as a current (bad) commit and checkout dda6897 new: background image and initial styling to see if the bug exists there. It doesn’t – so we have a good commit (dda6897) and a bad commit (0695d06), surely the bug was created somewhere in between!
Let’s start searching by typing git bisect start. Then you give it the good commit by typing git bisect good dda6897and a the bad one git bisect bad 0695d06
It says that it would take roughly 2 steps, only because we have only 8 commits, but surely you can’t even beat that if you are searching manually! Anyway, git has already checked out a branch from the middle of the list (cc7621e new: set h1 width), so go and open the index.html in the browser to check if the error is still there? In our case the title on the page isn’t correct and (cc7621e)has the bug, so we tell git by saying git bisect bad and it automatically checks out the the next commit, which takes us to 88ec177 fix: header tag margin. Git bisect has halved the possible options, so it will continue going through the commits between dda6897 and cc7621e, it won’t bother with the upper half of the list. When you have hundreds of commits this will save you so much time!
Again, the commit is bad, so we tell git by typing git bisect bad and this gives us the final result, that the bug was created as part of a change done in `67f482e fix: background position`.
After a successful session, reset the bisect state and return to the original head by typing git bisect reset
If you’d like to see what changed, use git show 67f482e or if you have checked it out and HEAD is pointing at that commit, just do git show.I prefer to use a VS Extention for this called GitLens and I highly recommend giving a go!
git bisect has other options as well, the above covers the fundaments, but feel free to explore more of it from the git bisect page.
If you have any questions, feel free to message me, including If you’d like to know where the index.html background image is from! Happy coding!