Git is probably one of the most important and revolutionary open source projects to be ever created in the history of software development. and over the years it has added awesome tools to make life easier for developers who just don't exactly know what they're doing (count me in). one of those many awesome tools is git bisect
What is git bisect you ask?
well if you are coming from a software engineering background you might have heard about a searching algorithm called binary search
, the very core of this searching algorithm dictates that if there is progressive order maintained in a sequence of numbers and if you want to search for a specific entry you can use this iterative approach to cut the search space in half at each iteration, for example, if you know a point "A" and another point "B" and these two have a progressive sequence in between at each iteration you could cut the search space in half.
Now git bisect uses this same algorithm but just for finding the things we have messed up in our codebase.
it assumes you have faced some bug in your code that is caused by some other commit that you have no idea about, but you're sure it wasn't there, and you probably know the commit when everything was working just fine (you know before ? before shit got real?). now you have to figure out after which commit things hit the fan. git bisect just does this using a binary search between the good commit and the current one and at each iteration, it gives a middle ground to start with
we'll do this using an example
In this demo project, we have made 5 different commits with some changes to demonstrate a wide space to use bisect
- First we assume the current head is the bad commit where we are facing the issue for sure, so just log the git history to find a commit where we are certain that everything works fine (probably the last production build where everything worked), so open the terminal and hit:
git log
commit ec802e7ad3547eab0475a95ea8165ad39a096ed6 (HEAD -> master)
Author: Akashdeep <adeep8961@gmail.com>
Date: Fri Aug 5 00:04:49 2022 +0530
feat: commit 5
commit aef6d0f4f4a8c9404a07fbb07805c14afb1913e4
Author: Akashdeep <adeep8961@gmail.com>
Date: Fri Aug 5 00:04:36 2022 +0530
feat: commit 4
commit 8dae945d335e488f38faa7bb2d32f963897a349c
Author: Akashdeep <adeep8961@gmail.com>
Date: Fri Aug 5 00:04:23 2022 +0530
feat: commit 3
commit 114b05be372ddb6e6674fe3c3270161ef549a4c4
Author: Akashdeep <adeep8961@gmail.com>
Date: Fri Aug 5 00:04:11 2022 +0530
feat: commit 2
commit 53687b93af435041d1f2b1895839564e6c1f97cd
Author: Akashdeep <adeep8961@gmail.com>
Date: Fri Aug 5 00:03:53 2022 +0530
feat: commit 1
commit 7e33d507ce19a4eba677ecadb9f74ea4f3b3d1f6
Author: Akashdeep <adeep8961@gmail.com>
Date: Thu Aug 4 23:58:25 2022 +0530
init: first commit
for this demo let's assume commit number 1 is the one that is safe for sure so just copy the commit hash for commit 1
- Starting the bisect session and mark the initial commit points
you can probably see the bisect session indicator in the terminal
now let's mark the current head/commit as bad
git bisect bad
after this, you need to mark the commit id you copied earlier as a good commit to doing the first bisection
git bisect good 53687b93af435041d1f2b1895839564e6c1f97cd
after you mark the first search space your bisection starts
after the bisection, git automatically checks out with a commit in the exact middle of the space for you to test, now after we test the code for this commit and decide this still is a bad commit we can mark this commit as the new bad commit and continue with the bisect process.
for the demo, let's mark this as a bad commit
git bisect bad
now here git checks out to commit 2, and we decide this is a working code commit (we can continue this process to find exactly where the last screwup happened).
git bisect good
now as you can see after the bisect session ended we have all the history and at which commit our code did exactly break.
now just copy the commit hash for commit 3(bad commit) & we can check the changes for this commit using
git show 8dae945d335e488f38faa7bb2d32f963897a349c
and if we decide this change is isolated and could be simply reverted. now first end the session of bisect and run
git bisect reset
git revert 8dae945d335e488f38faa7bb2d32f963897a349c
and we have successfully debugged a production-grade issue (hell yeah !!!!!).
Do comment on the post to add any more points or to imrove the overall quality of it.
Feel free to follow me on other platforms as well
Top comments (2)
I already knew the feature, but your article is great.
Thank you