git bisect
Ever faced a situation where you made multiple commits to your project only to break a feature which you are sure it worked properly before you went on the commit spree?
How on earth do you even plan to begin debugging the code in such a scenario?
One could go on a brute force approach but wouldn't it be much easier(to debug) if git just tells you which commit messed up your feature?
git bisect does exactly that.
Suppose I have a commit history as shown below:
Lets say my feature worked properly in 29aa243. I want to find which commit between 29aa243 and d3bf6d2 broke my feature.
Before beginning to bisect the commits, lets get a basic understanding of the involved commands
To start bisecting, we run the command :
git bisect start
This would start a bisecting session where you have to test your feature and tell git if it works fine or is still broken.
git bisect good [optional commit] # If the feature works fine
git bisect bad [optional commit] # If the feature is still broken
This is a simple logic graph of the process:
Now, We have to first initialize which commit is good and which is bad . In this scenario, my d3bf6d2 (current HEAD) is bad and 29aa243 is good. Do this with the help of commands given above
Now test your feature and subsequently go through the logic graph given above(Note: It is very important that you donot begin to commit on the codebase in a Bisecting Session. Since the HEAD remains in a detached state in such session, it would give you a hard time fixing everything later. See the last part of this article on how to exit Bisecting Session).
In the end of all revisions, git will tell which commit broke your feature :]
Now that you have found your guilty commit, its time to reattach your Detached HEAD back to master. Do this to reattach your detached HEAD
git bisect reset
Good luck with debugging that commit 👍. Here are some more sources to learn about git bisect :
https://git-scm.com/docs/git-bisect
https://stackoverflow.com/questions/4713088/how-to-use-git-bisect
Top comments (0)