Picture yourself in this scenario
You’ve been working on a branch for the past 3 days. 30 commits later you are ready to complete your feature when all of a sudden. You realize that something is wrong with the footer of your application. As you panic, you look at your previous commits to see if anything has changed in the footer. In fact, the footer has not been touched and you have no idea what’s going on.
With git bisect you could save countless hours of trying to find the exact commit that introduced the bug, without having to go commit by commit.
git bisect will perform a binary search to help you find the exact commit you’re looking for. If you are unfamiliar with a binary search it basically means it will divide the options in half each time as you answer a simple question Does the commit that it is showing you have the bug or not.
How To use
Now, to start the process use git bisect start. After doing this nothing happens... What you then need to do is supply git with a commit that you know where the bug not present or a ‘good’ commit git bisect good ch4792h2 for example. Then enter the second commit which has a known instance of the app with the bug, in other words, a ‘bad commit’ such as git bisect bad ke37lw5
After doing this git will checkout a commit for you that you will then have to respond with git bisect good if the commit it's showing you does not have the bug or git bisect bad if it does. After answering, git will narrow the search by removing the other half of the commits, then asking you the same question. Eventually narrowing down to the commit that introduced the bug.
And that’s it! In about 4 to 5 commits you were able to find the commit that introduced the bug. Now, this might be more beneficial for checking for changes in the UI since you can clearly see when something in the app is not working like its supposed to. However, it is a nice command to remember from time to time if something ever comes up
Top comments (8)
This is great! Just this week this wouldn’t been helpful at work.
Thank you! I hope it'll save you some time in the future
How does this compare to git blame command, that one seems simpler, at least through InteliJ?
Hey, great question. I have never used InteliJ however from my understanding of
git blame. It gives you line by line the commit history of a specific file. So that could be helpful if you know or have an idea of where a bug or defect could have been introduced, just scan the file and find it. However, if on your branch you have made updates to multiple files and are not sure where the bug could have come from. Then git bisect will help by allowing you to quickly see the outcome of your code by going through commits for you. So like I mentioned in the article it might be more useful when you are doing front end / ui work and want to visually see changes.Thank you.
This a good tool and useful, but we can avoid a lot of commits in one branch it's a bad practice, maybe for 3 days of work has 6 commits at most
Thank you! And yes, you are correct about the number of commits. I used an arbitrary and exaggerated value just for the example.
Very helpful command. You have explained it nicely. But don't you think it should have the option to send good and bad commits in the first command itself. Why 3 commands for that?