Git Bisect : Find that DAMN Commit!!!
While working on a project with a team, there is a chance that once in a while erroneous pieces of code (bad programming, wrong conflict resolution etc) creep in. Now wading thorugh individual commits looking for a specific line in a file that looks suspicious can be hard work and takes a lot of time.
I was in one of these situations recently and decided early on that rather than take the Brute -Force approach of wading through each of those files, i’d rather use something that GIT already provides …. GIT BISECT
So lets find that commit in 5 simple steps and kick it’s a$$. First thing is to start it up …
1) Fire up the engines …
[shell]git bisect start[/shell]
This will start the Bisect process within the current branch.
2) Define the range at which your target resides ….
Next we need to define the start and end points in which to search for the bad commit..
Find the commit for which the code is working as needed and mark it as ‘good’
[shell]git bisect good [/shell]
After that find the commit for which the code does not work as expected and mark it as ‘bad’
[shell]git bisect bad [/shell]
The good commit will always precede the bad commit*. On doing this, GIT would find the middle most commit between the 2 commits marked above, display the commit details on console and checkout that version .. all in one go 🙂
3) Fire …
Now the next step is to simply run that checkout version and see if it works accordingly. If it does mark it as
[shell]git bisect good[/shell]
else
[shell] git bisect bad [/shell]
On doing this git would now traverse between the last commit marked as ‘good’ and ‘bad’ and find out the middlemost and checkout that version.
4) Reload ….
Repeat step 3 until you it spews out the commit that was causing the error, until you see something like
5) Turn off the engine..
Once that is done all you need to do is
[shell] git bisect reset[/shell]
to stop the engine ..
* Additional Notes
A good commit will always precede a bad commit because we are finding the buggy code/commit and not the one where the code has been fixed. So git assumes that the code is still error prone and we are searching for the same.
To review what all has been accomplished in this process of marking good/bad you can hit git bisect log to view a list of commits analysed
If you know for sure that a certain commit is not the one, you can skip it to speed up the process by issuing a git bisect skip [commit] command. It can also skip a range of commits using git bisect skip [commit]… [commit]
Hope this helps …
Manoj Mohan
manoj[at]intelligrape[dot]com
