找了一天找不到 Bug？试试 Git 的二分法吧！

正文共： 2221字 11图

预计阅读时间： 6分钟

你一定遇到过，一个很久没修改过的功能，莫名其妙的出现了问题？肉眼查代码、屡逻辑完全找不到问题点？前两天还好好的功能，怎么这个今天就不行了？这两天改动了这么多代码，到底是那一次改动引发的 Bug？

这样非崩溃的 Bug，有时候想要排查出问题，并不是一件容易的事情。我想，这个时候你会需要 git bisect !一、git bisect 基础使用git bisect 是 Git 提供的一种二分法的调试工具，它可以按照我们选定的提交，进行二分分割，快速定位出出错的提交。来帮我们缩小最小改动的代码，从而快速定位问题。git bisect 其实很简单，主要是基于几个基本命令：

git bisect start：准备进行 bisect debug。

git bisect good：标记一个提交为 "good"。

git bisect bad：标记一个提交为 “bad”。

git bisect reset：退出 bisect debug 的状态。

git bisect 涉及到的命令，非常的清晰简单，下面举个实际的例子，结合上面的解释，就更清晰了。二、git bisect 工作流我自己生造出 6 个 commit，然后使用 看看我的提交记录。

这里假设我正常开发的阶段，到v6提交的时候，突然发现有个 Bug ，无法定位到问题，但是能明确的知道，在v1提交阶段，并没有这个 Bug。那么，在这样的情况下，v6就是一个有问题的版本，而v1则是一个好的版本，我们就可以借助 来进行二分超找定位问题来自哪个提交。还记得刚才的命令吗？我们先用 标记开始bisect debug，然后使用 和 分别标记出正确的和错误的提交。

每个提交，都有一个针对这个提交唯一的SHA-1值，因为太长不方便输入和阅读，这里可以直接使用前几位作为简写。当标记处正确的和错误的提交之后， 立刻就可以帮我们定位出中间提交v3。现在HEAD就已经指向了v3提交的代码了，这个可以使用 查看当前的状态。

所以我们可以基于v3版本的代码，直接运行项目，测试看该提交是否有问题。经过测试之后，发现v3的提交代码版本，并没有复现 Bug，那我们就可以缩小错误提交的范围，大概落在了v4、v5、v6之间。此时，我们只需要使用 标记v3版本是正确的。

标记好v3为good之后，立刻又会进行一次二分，此次标记的为中间提交v5。经过对v5提交的版本代码，进行测试之后发现，它是有问题的。我们继续使用 对它进行标记。

当v5有问题的时候，现在只中间一个v4版本，所以会立刻指向v4提交。我们继续对v4版本的代码进行测试，发现v4版本也有问题，继续标记它为bad。

此时就很明确了，出错的提交就是v4，而 Git 也直接帮我们指出来出错的提交。虽然这里定位到，出错的提交就是v4的问题，我们只需要仔细阅读v4提交的代码，然后定位出问题代码，就达到了我们的目的。但是我们并不应该在v4提交上直接修改 Bug，我们应该退出 bisect debug 状态，在最新的提交版本上进行修改，这里使用 退出，再进行修改即可。到这里，就是 的完整工作流程。三、bisect的后悔药对提交进行good和bad的标记，都是人为来进行的，难免有出错的情况。而提交比较少的时候，大不了就是 reset 之后，重头来过。但是如果有几十个提交，再从头进行一次 bisect 就比较麻烦了。Git 考虑到这一点，已经为我们配好了后悔药。想要擦除之前的标记状态，就涉及到一个命令：

git bisect replay：重置到某个状态。

replay 需要制定一个回退的点，这个点是需要使用 输出的 Log 文件， 我们需要通过修改这个 Log 文件，来确定回退的点。举个例子，我们使用 log 命令，输出一个log.txt文件。

可以看到，这个 log.txt 文件，记录了我们刚才所有的操作。在这个例子中，假如我们的操作，对v5进行bad的这个标记错了，那么，我们把这个操作之下的 Log 全部删除掉，然后执行 。

这样就将回退到判断v5提交好坏的地方，重新进行标记。在修改 Log.txt 文件的时候，最好只执行删除操作，不要对其中的顺序有所修改，毕竟我们只是想要一个回滚的动作，并不是要改动我们之前的某些操作。

git bisect 的全部内容就这些了，你觉得对你受用吗？或者你有什么更方便的定位 Bug 的方法，可以在留言区讨论。