你一定遇到过很久没有修改的功能，出现莫名其妙的问题？肉眼查代码，重复逻辑，根本找不到问题？前两天功能还好，今天怎么就不行了？这两天改了那么多代码，是哪一个导致了bug？有时要解决这种非崩溃错误并不容易。我想这时候你会需要gitbisect！一、Gitbisect基础Gitbisect是Git提供的二分调试工具。它可以根据我们选择的提交进行二分法，快速定位到错误的提交。快来帮我们缩小改动最小的代码范围，以便快速定位问题。gitbisect其实很简单，主要是几个基本的命令：gitbisectstart：准备bisect调试。gitbisectgood：将提交标记为“好”。gitbisectbad：将提交标记为“坏”。gitbisectreset：退出bisect调试状态。gitbisect涉及的命令非常清晰和简单。这里举一个实际的例子，结合上面的解释，就会更清楚了。2.Gitbisectworkflow我自己生成了6个commit，然后用gitlog查看我的commit记录。这里假设在我正常的开发阶段，提交v6的时候，突然发现一个bug，无法定位问题，但是在v1提交阶段，我可以清楚的知道没有这个bug。那么，这种情况下，v6是有问题的版本，v1是好的版本，我们可以使用gitbisect进行二进制超查找，定位出问题出在哪个commit上。还记得刚才的命令吗？我们使用gitbisect开始标记开始bisectdebug，然后使用gitbisectgood和gitbisectbad分别标记正确和错误的提交。每一次提交对于本次提交都有一个唯一的SHA-1值，因为输入和阅读太长，所以这里可以直接使用前几位作为缩写。标记正确和错误的提交后，gitbisect可以帮助我们立即定位到中间提交v3。现在HEAD已经指向了v3提交的代码，可以通过gitstatus查看。所以我们可以直接基于v3版本的代码运行项目，测试提交是否有问题。经过测试，发现提交的代码版本v3并没有重现bug，那么我们可以缩小错误提交的范围，大概在v4、v5、v6之间。此时，我们只需要用gitgood将v3版本标记为好。将v3标记为good后，马上又会进行两点标记，这次标记的是中间commitv5。测试v5提交的版本代码，发现是有问题的。我们继续用gitbisectbad标记它。当v5出现问题时，中间只有一个v4版本，所以会立马指向v4提交。我们继续测试v4版本的代码，发现v4版本也有问题，继续标记为bad。这时候就很清楚错误的提交是v4了，Git也直接给我们指出了错误的提交。虽然定位到这里提交错误是v4的问题，但是我们只要仔细阅读v4提交的代码，然后定位到问题代码，就达到了我们的目的。但是我们不要直接在v4提交上修改bug，应该退出bisectdebug状态，在***提交的版本上修改，这里使用gitbisectreset退出，再修改。这是gitbisect的完整工作流程。3.Bisect的后悔药将提交标记为好与坏，都是人为做的，错误在所难免。投稿比较少的时候，大不了reset后重新开始。但是如果有几十个commit的话，从头再做一次bisect就比较麻烦了。考虑到这一点，Git为我们准备了后悔药。要清除之前标记的状态，涉及一个命令：gitbisectreplay:resettoacertainstate。Replay需要做一个回滚点，也就是gitbisectlog>log.txt需要输出的Log文件。我们需要修改这个Log文件来确定回滚点。比如我们使用log命令输出一个log.txt文件。可以看到，这个log.txt文件记录了我们刚才的所有操作。在这个例子中，如果我们的操作，badforv5的标记是错误的，那么我们删除这个操作下的所有Log，然后执行gitbisectreplaylog.txt。这样会回退到v5提交判断好坏的地方，重新标记一下。修改Log.txt文件时，最好只进行删除操作，不要修改其中的顺序。毕竟我们只是想要一个回滚动作，而不是改变我们之前的一些操作。【本文为专栏作家“张扬”原创稿件，转载请微信♂联系作者获得授权】点此查看作者更多好文
