你一定遇到过，一个很久没修改过的功能，莫名其妙的出现了问题？肉眼查代码、屡逻辑完全找不到问题点？前两天还好好的功能，怎么这个今天就不行了？这两天改动了这么多代码，到底是那一次改动引发的 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，然后使用 git log 看看我的提交记录。

这里假设我正常开发的阶段，到 v6 提交的时候，突然发现有个 Bug ，无法定位到问题，但是能明确的知道，在 v1 提交阶段，并没有这个 Bug。

那么，在这样的情况下，v6 就是一个有问题的版本，而 v1 则是一个好的版本，我们就可以借助 git bisect 来进行二分超找定位问题来自哪个提交。

还记得刚才的命令吗？

我们先用 git bisect start 标记开始 bisect debug ，然后使用 git bisect good 和 git bisect bad 分别标记出正确的和错误的提交。

每个提交，都有一个针对这个提交唯一的 SHA-1 值，因为太长不方便输入和阅读，这里可以直接使用前几位作为简写。

当标记处正确的和错误的提交之后，git bisect 立刻就可以帮我们定位出中间提交 v3。

现在 HEAD 就已经指向了 v3 提交的代码了，这个可以使用 git status 查看当前的状态。

所以我们可以基于 v3 版本的代码，直接运行项目，测试看该提交是否有问题。

经过测试之后，发现 v3 的提交代码版本，并没有复现 Bug，那我们就可以缩小错误提交的范围，大概落在了 v4、v5、v6 之间。

此时，我们只需要使用 git good 标记 v3 版本是正确的。

标记好 v3 为 good 之后，立刻又会进行一次二分，此次标记的为中间提交 v5。

经过对 v5 提交的版本代码，进行测试之后发现，它是有问题的。我们继续使用 git bisect bad 对它进行标记。

当 v5 有问题的时候，现在只中间一个 v4 版本，所以会立刻指向 v4 提交。

我们继续对 v4 版本的代码进行测试，发现 v4 版本也有问题，继续标记它为 bad 。

此时就很明确了，出错的提交就是 v4，而 Git 也直接帮我们指出来出错的提交。

虽然这里定位到，出错的提交就是 v4 的问题，我们只需要仔细阅读 v4 提交的代码，然后定位出问题代码，就达到了我们的目的。但是我们并不应该在 v4 提交上直接修改 Bug，我们应该退出 bisect debug 状态，在最新的提交版本上进行修改，这里使用 git bisect reset 退出，再进行修改即可。