Most of my time working as a software engineer is spent tracking down and fixing bugs. While a good portion of the bugs are my own doing, some of the bugs were created by other engineers, which makes the task more ambiguous. As the codebase grows, finding bugs becomes increasingly difficult. It's a time sink and super boring to manually click through every suspicious commit to find the culprit. However, you can automate this process by using a tool called git bisect.
What is git bisect?
Git bisect is based on a binary search algorithm, but don't worry, you won't need to dust off your old data structure textbooks! Git does all the work of repetitively dividing the commits in half, checking out commits, and helping you identify when new changes were introduced.
How do you use git bisect?
To let git know you want to start the process run :
git bisect start
git bisect good < commit’s SHA, tag or branch >
git bisect bad < commit’s SHA, tag or branch >
Git will checkout a commit between the two commits you provided. It will ask you to determine if that commit is good or bad, so play around with that copy of your code and see if the bug still exists. If it still exists, run git bisect bad again. Git will continue to narrow down the commits until you find the culprit -- allowing an easier process of elimination. Using this, I realize I had the advantage of expending less brain power on finding the bug and more brainpower on fixing it.
Did you find the bug?
If so, run:
git bisect reset
This will tell git to stop bisecting. Then you can check out the offending commit, and start refactoring.
Warning: For this to work well, you will need a linear commit history.
Without a linear commit history, the history wouldn't show a true reflection of when code changes were made. To achieve a linear history, utilize git rebase and git squash and merge.
Comment below to tell me if it worked for you!
I originally wrote this post on https://www.blackgirlbytes.com/
Top comments (0)