{"id":6344,"date":"2012-09-24T16:49:26","date_gmt":"2012-09-24T11:19:26","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=6344"},"modified":"2016-12-19T14:46:32","modified_gmt":"2016-12-19T09:16:32","slug":"git-bisect-find-that-damn-commit","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/git-bisect-find-that-damn-commit\/","title":{"rendered":"Git Bisect : Find that DAMN Commit!!!"},"content":{"rendered":"<p>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<p style=\"padding-bottom: 10px\">\n<p>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&#8217;d rather use something that GIT already provides &#8230;. <strong>GIT BISECT<\/strong><\/p>\n<p style=\"padding-bottom: 10px\">\n<p>So lets find that commit in 5 simple steps and kick it&#8217;s a$$. First thing is to start it up &#8230;<\/p>\n<p style=\"padding-bottom: 10px\">\n<h5><strong>1) Fire up the engines &#8230;<\/strong><\/h5>\n<p>[shell]git bisect start[\/shell]<\/p>\n<p>This will start the Bisect process within the current branch.<\/p>\n<p style=\"padding-bottom: 10px\">\n<h5><strong>2) Define the range at which your target resides &#8230;.<\/strong><\/h5>\n<p>Next we need to define the start and end points in which to search for the bad commit..<br \/>\nFind the commit for which the code is working as needed and mark it as &#8216;good&#8217;<\/p>\n<p>[shell]git bisect good  [\/shell]<\/p>\n<p>After that find the commit for which the code \u00a0does not work as expected and mark it as &#8216;bad&#8217;<\/p>\n<p>[shell]git bisect bad [\/shell]<\/p>\n<p style=\"padding-bottom: 10px\">\n<p>The good commit will always precede the bad commit<strong>*<\/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<p style=\"padding-bottom: 10px\">\n<h5><strong>3) Fire &#8230;<\/strong><\/h5>\n<p>Now the next step is to simply run that checkout version and see if it works accordingly. If it does mark it as<br \/>\n[shell]git bisect good[\/shell]<\/p>\n<p style=\"padding-bottom: 10px\">\n<p>else<br \/>\n[shell] git bisect bad [\/shell]<\/p>\n<p style=\"padding-bottom: 10px\">\n<p>On doing this git would now traverse between the last commit marked as &#8216;good&#8217; and &#8216;bad&#8217; and find out the middlemost and checkout that version.<\/p>\n<p style=\"padding-bottom: 10px\">\n<h5><strong>4) Reload &#8230;.<\/strong><\/h5>\n<p>Repeat step 3 until you it spews out the commit that was causing the error, until you see something like<\/p>\n<p style=\"padding-bottom: 10px\">\n<p style=\"padding-bottom: 10px\">\n<h5><strong>5) Turn off the engine..<\/strong><\/h5>\n<p>Once that is done all you need to do is<br \/>\n[shell]\u00a0git bisect reset[\/shell]<br \/>\nto stop the engine ..<\/p>\n<p style=\"padding-bottom: 10px\">\n<h5><strong>* Additional Notes<\/strong><\/h5>\n<p><em>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<p style=\"padding-bottom: 10px\">\n<p>To review what all has been accomplished in this process of marking good\/bad  you can hit <strong> git bisect log<\/strong> to view a list of commits analysed<\/p>\n<p style=\"padding-bottom: 10px\">\n<p>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 <strong>git bisect skip [commit] <\/strong> command. It can also skip a range of commits using <strong>git bisect skip  [commit]&#8230; [commit]<\/strong><\/em><\/p>\n<p style=\"padding-bottom: 10px\">\n<p style=\"padding-bottom: 10px\">\n<p>Hope this helps &#8230;<\/p>\n<p><strong>Manoj Mohan<br \/>\nmanoj[at]intelligrape[dot]com<\/strong><\/p>\n<p style=\"padding-bottom: 10px\">\n","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":32,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":2},"categories":[1],"tags":[375,1045,461],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/6344"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/32"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=6344"}],"version-history":[{"count":0,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/6344\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=6344"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=6344"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=6344"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}