We all hate searching for the cause of a nasty regression. There’s no doubt about it. It is time-consuming, frustrating, and it stops you from doing what excites you.
That’s when clean git history comes into play.
Instead of hunting the bug by inspecting or debugging the code, you could find the git commit which introduced the regression. More often than not, it will be obvious why it happened, and what should you do to fix it.
If you know of one good revision and have encountered a bad one, then somewhere in between those two lies the commit which introduced the regression.
Git bisect helps you do the binary search between these two by checking out revisions and asking you to verify if it’s good or bad one.
log(n) of builds, where
n is the number of commits between initial good and bad.
For more, consult git-bisect
Check out the previous issue.