There are some situations that you found your build broken and need to know at what revision the “brokeness” was introduced.
git bisect is a great tool for that, basically you tell git at which revision
the build was good (assuming HEAD is broken), and it does a binary search for the revision where
the bug was introduced.
How it works:
git bisect start git bisect good SOME_WORKING_PAST_REVISION
git will tell your how many revisions are between
and how many steps it will take.
Then it will walk you through each step (revisions), where you manually mark them good or bad.
If the revision still works, you mark it as good:
git bisect good
If the revision doesn’t work, you mark it as bad:
git bisect bad
When you reach the last step git will tell you at what revision the bug was introduced.
The good stuff
You can automate this process if you have test coverage on the bug.
run argument that accepts an external program to automatically flag a
revision as good or bad. This makes things very easy:
git bisect start git bisect good WORKING_PAST_REVISION git bisect run rspec spec/models/user_spec.rb ... ... abcde1234def is the first bad commit commit abc1234def5678 Author: John Snow <firstname.lastname@example.org> Date: Thu Dec 23 13:37:00 2010 +0100 Some stuff