Introduction
Yesterday I was working on a task and I made changes in a few files. When committing the changes, right before pushing them to a remote branch, I added a couple of more small changes, created a few more commits and done, pushed all the commits. When running the application again I got an error, which I couldn't identify which of the changes or commits was related to.
And that's when git bisect came across while I was trying to debug.
What does the git bisect command do?
git bisect is a command in Git that helps find the commit that introduced a bug or caused a regression in your codebase. It uses a binary search algorithm to efficiently narrow down the range of commits to be examined. By marking specific commits as “good” or “bad”, git bisect automatically selects the next commit for testing until it identifies the exact commit that introduced the issue. This process helps identify the faulty commit more quickly and efficiently, enabling developers to pinpoint and fix the problem more effectively.
An example on how to use it
Using the GitLens extension in VSCode I picked one of the previous commits guessing it didn’t contain any errors (you can use git log to do that as well), and to make sure it was working fine I checked out to that commit and ran the application from that point, checking if the error was there or not. Once it hasn’t any errors I decided to pick that commit to start to bisect.
So I started the git bisect with the flawed commit id - which was my last commit - to indicate it’s a bad commit:
git bisect start <flawed_commit_id>
Git will mark it as a bad commit and then expect for the id of a good commit. So I copied and pasted the id of that commit I ran previously to make sure it wasn’t broken in order to run the following command:
git bisect good <good_commit_id>
Git will now automatically checkout a commit in the middle of the range between the known good commit and the bad commit. This commit represents the midpoint of the binary search. So I was able to run my application using the returned commit to test if the application was already crashed or not, so that I could tell Git to mark the commit as good or bad using git bisect good or git bisect bad.
Repeat the process: Git will continue selecting commits for testing based on the binary search algorithm. You repeat the previous step by testing the code and telling Git to mark it as good or bad commit until you narrow down to the exact commit that introduced the bug.
Finish the bisect: Once you identify the faulty commit, you can run git bisect reset to exit the bisect mode and return to the latest commit.
Conclusion
By systematically cutting down the range of commits through binary search, git bisect helps efficiently locate the faulty commit in your code history.
Top comments (1)
Too bad this is a pain to do in Unity. Not only are you likely to have to rebuild parts of the library each time you do a jump, but if any files get generated or modified automatically then that will complicate things.
Hoping I some day will have a use for this on a project where jumping back and forth and testing for an issue can be done quickly