When you have a broken version of your code and you want to locate when(the specific commit) it got broken you will probably need to check-out each commit, build your app and check if the bug still exists, this called a linear search and while it’s very simple and easy to understand it can take a lot of time and effort when there are hundreds of commits. That is exactly what the git bisect command does only with binary search which is more efficient then a linear search.
As Elcio said the git bisect command helps you find the commit where the bug interduced. However, if you already know on which commit it happened then you don't need the git bisect at all. 😎
First, thank you for your feedback😊
When you have a broken version of your code and you want to locate when(the specific commit) it got broken you will probably need to check-out each commit, build your app and check if the bug still exists, this called a linear search and while it’s very simple and easy to understand it can take a lot of time and effort when there are hundreds of commits. That is exactly what the git bisect command does only with binary search which is more efficient then a linear search.
As Elcio said the git bisect command helps you find the commit where the bug interduced. However, if you already know on which commit it happened then you don't need the git bisect at all. 😎
That's Very Nice To Mention Here and For Sure Looking Forward to Give it a try as well.