漫画：Git 二分 Debug，火速定位出错代码！

承香墨影

只分享最有用的原创技术干货！

关注

Git bisect 是 Git 提供的一种二分法的调试工具，它可以按照我们选定的 commit 列表，进行二分分割，快速定位出出错的 commit。来帮我们缩小最小改动的代码，从而快速定位问题。

Git bisect 其实很简单，主要是基于几个基本命令：

git bisect start：准备进行 bisect debug。

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

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

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

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 文件的时候，最好只执行删除操作，不要对其中的顺序有所修改，毕竟我们只是想要一个回滚的动作，并不是要改动我们之前的某些操作。