While working on a project with a team, there is a chance that once in a while\u00a0erroneous\u00a0pieces\u00a0of 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.<\/p>\n
\n
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<\/strong><\/p>\n \n So lets find that commit in 5 simple steps and kick it’s a$$. First thing is to start it up …<\/p>\n \n [shell]git bisect start[\/shell]<\/p>\n This will start the Bisect process within the current branch.<\/p>\n \n Next we need to define the start and end points in which to search for the bad commit.. [shell]git bisect good [\/shell]<\/p>\n After that find the commit for which the code \u00a0does not work as expected and mark it as ‘bad’<\/p>\n [shell]git bisect bad [\/shell]<\/p>\n \n The good commit will always precede the bad commit*<\/strong>. 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 \ud83d\ude42<\/p>\n \n Now the next step is to simply run that checkout version and see if it works accordingly. If it does mark it as \n else \n 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.<\/p>\n \n Repeat step 3 until you it spews out the commit that was causing the error, until you see something like<\/p>\n \n \n Once that is done all you need to do is \n 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.<\/p>\n \n To review what all has been accomplished in this process of marking good\/bad you can hit git bisect log<\/strong> to view a list of commits analysed<\/p>\n \n 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] <\/strong> command. It can also skip a range of commits using git bisect skip [commit]… [commit]<\/strong><\/em><\/p>\n \n \n Hope this helps …<\/p>\n Manoj Mohan \n","protected":false},"excerpt":{"rendered":" While working on a project with a team, there is a chance that once in a while\u00a0erroneous\u00a0pieces\u00a0of 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 […]<\/p>\n","protected":false},"author":32,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":4,"footnotes":""},"categories":[1],"tags":[375,1045,461],"class_list":["post-6344","post","type-post","status-publish","format-standard","hentry","category-technology","tag-git","tag-git-bisect","tag-vcs"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t1) Fire up the engines …<\/strong><\/h5>\n
2) Define the range at which your target resides ….<\/strong><\/h5>\n
\nFind the commit for which the code is working as needed and mark it as ‘good’<\/p>\n3) Fire …<\/strong><\/h5>\n
\n[shell]git bisect good[\/shell]<\/p>\n
\n[shell] git bisect bad [\/shell]<\/p>\n4) Reload ….<\/strong><\/h5>\n
5) Turn off the engine..<\/strong><\/h5>\n
\n[shell]\u00a0git bisect reset[\/shell]
\nto stop the engine ..<\/p>\n* Additional Notes<\/strong><\/h5>\n
\nmanoj[at]intelligrape[dot]com<\/strong><\/p>\n