回归是软件行业中的一个大问题。但很难用真实的数字来支持这一说法。

关于一般性错误有一些数据，例如 2002 年的一项 NIST 研究 [1] 指出：

此外：

最终的结论始于：

还有其他估计称，与软件相关的成本中有 80% 是关于维护的 [2]。

然而，根据维基百科 [3]：

但我们可以推测，改进现有软件的成本非常高昂，因为您必须警惕回归。至少这会使上述研究之间保持一致。

当然，有些软件被开发出来后，使用一段时间后没有太多改进，然后最终被淘汰。在这种情况下，回归可能不是一个大问题。但另一方面，有许多大型软件是由大量人员持续开发和维护多年甚至几十年。而且由于通常有很多人（有时是关键性地）依赖此类软件，因此回归是一个真正的大问题。

Linux 内核就是其中之一。如果我们看一下 Linux 内核，会发现大量时间和精力都用于对抗回归。发布周期从为期两周的合并窗口开始。然后标记第一个发布候选 (rc) 版本。之后，在大约一周的间隔内，将出现约 7 或 8 个更多的 rc 版本，然后才发布最终版本。

第一个 rc 版本发布到最终版本发布之间的时间，旨在用于测试 rc 版本并修复错误，特别是回归。这段时间占发布周期总时间的 80% 以上。但这还不是斗争的结束，因为在发布之后，斗争当然还在继续。

Ingo Molnar（一位著名的 Linux 内核开发者）关于他使用 git bisect 的说法是：

因此，开发人员一直在与回归作斗争，而且众所周知，bug 应该尽快修复，即一发现就修复。这就是为什么拥有良好的工具用于此目的很有意义。

那么，用于对抗回归的工具是什么呢？它们与用于对抗常规错误的工具几乎相同。唯一的特定工具是测试套件和类似于“git bisect”的工具。

测试套件非常好。但当它们单独使用时，通常需要在每次提交后检查所有测试。这意味着它们的效率不高，因为许多测试运行后没有有意义的结果，而且它们会遭受组合爆炸的影响。

实际上，问题在于大型软件通常有许多不同的配置选项，并且每个测试用例在每次提交后都应该针对每个配置通过。因此，如果您在每个版本中都有：N 个配置、M 次提交和 T 个测试用例，您应该执行：

其中 N、M 和 T 都随着您的软件规模的增长而增长。

因此，很快就无法完全测试所有内容。

如果某些错误通过了您的测试套件，那么您可以向测试套件中添加一个测试。但如果您想使用新的改进测试套件来查找错误是从哪里溜进去的，那么您将不得不模拟一个二分查找过程，或者您可能会直接从您拥有的“坏”提交开始向后测试每个提交，这可能非常浪费。

第一个要使用的“git bisect”子命令是“git bisect start”，用于开始搜索。然后必须设置界限以限制提交空间。这通常通过提供一个“坏”提交和至少一个“好”提交来完成。它们可以在首次调用“git bisect start”时像这样传递：

或者它们可以通过以下方式设置：

和

其中 BAD、GOOD 和 COMMIT 都是可以解析为提交的名称。

然后，“git bisect”将检出它选择的一个提交，并要求用户测试它，如下所示：

请注意，我们将使用的示例只是一个玩具示例，我们将寻找第一个版本类似于“2.6.26-something”的提交，即在顶级 Makefile 中包含“SUBLEVEL = 26”行的提交。这是一个玩具示例，因为在 Git 中有比使用“git bisect”更好的方法来找到这个提交（例如“git blame”或“git log -S<string>”）。

此时，驱动搜索基本上有两种方式。它可以由用户手动驱动，也可以由脚本或命令自动驱动。

如果由用户驱动，那么在搜索的每一步，用户都必须测试当前提交，并分别使用前面描述的“git bisect good”或“git bisect bad”命令说明它是“好”还是“坏”。例如：

经过几步这样的操作后，“git bisect”最终会找到第一个坏提交：

此时，我们可以查看提交做了什么，检出它（如果尚未检出）或修改它，例如：

完成后，我们可以使用“git bisect reset”回到我们开始二分查找之前的分支：

驱动二分查找过程的另一种方式是告诉“git bisect”在每个二分查找步骤中启动一个脚本或命令，以判断当前提交是“好”还是“坏”。为此，我们使用“git bisect run”命令。例如：

在此示例中，我们向“git bisect run”传递了“grep *^SUBLEVEL = 25* Makefile”作为参数。这意味着在每个步骤中，我们传递的 grep 命令都将被启动。如果它以代码 0 退出（表示成功），则 git bisect 会将当前状态标记为“好”。如果它以代码 1 退出（或 1 到 127 之间的任何代码，特殊代码 125 除外），则当前状态将被标记为“坏”。

退出代码 128 到 255 对“git bisect run”来说是特殊的。它们会立即停止二分查找过程。这在例如传递的命令执行时间过长时非常有用，因为您可以用信号终止它，它会停止二分查找过程。

在传递给“git bisect run”的脚本中，如果检测到一些非常异常的情况，使用“exit 255”也很有用。

有时会发生当前状态无法测试的情况，例如，如果它因为当时存在一个阻止编译的错误而无法编译。这就是特殊退出代码 125 的作用。它告诉“git bisect run”，当前提交应被标记为无法测试，并且应选择并检出另一个提交。

如果二分查找过程是手动驱动的，您可以使用“git bisect skip”来执行同样的操作。（实际上，特殊退出代码 125 会使“git bisect run”在后台使用“git bisect skip”。）

或者如果您需要更多控制，可以使用例如“git bisect visualize”来检查当前状态。它将启动 gitk（如果未设置 `DISPLAY` 环境变量，则启动“git log”）以帮助您找到更好的二分查找点。

无论哪种方式，如果您有一连串无法测试的提交，那么您正在寻找的回归可能就是由其中一个无法测试的提交引入的。在这种情况下，无法确定是哪个提交引入了回归。

因此，如果您使用了“git bisect skip”（或运行脚本以特殊代码 125 退出），您可能会得到如下结果：

如果您想向其他人展示您的二分查找过程，可以使用例如以下命令获取日志：

并且可以使用以下命令回放它：

由于 Git 提交形成一个有向无环图 (DAG)，在每一步找到最佳的二分查找提交进行测试并不那么简单。无论如何，Linus 发现并实现了一个“真正愚蠢”的算法，后来经 Junio Hamano 改进，效果相当不错。

因此，“git bisect”在没有跳过提交的情况下寻找最佳二分查找提交所使用的算法如下：

1) 仅保留以下提交：

a) 是“坏”提交的祖先（包括“坏”提交本身）， b) 不是“好”提交的祖先（不包括“好”提交）。

这意味着我们剔除了 DAG 中不相关的提交。

例如，如果我们从一个像这样的图开始：

其中 B 是“坏”提交，“G”是“好”提交，W、X 和 Y 是其他提交，在第一步之后我们将得到以下图：

因此，只有 W 和 B 提交将被保留。因为提交 X 和 Y 将分别被规则 a) 和 b) 移除，并且提交 G 也被规则 b) 移除。

Git 用户请注意，这等同于只保留由以下命令给出的提交：

另请注意，我们不要求保留的提交是“好”提交的后代。因此在以下示例中，将保留提交 W 和 Z：

2) 从图的“好”端开始，为每个提交关联其祖先数量加一的值。

例如，对于以下图，其中 H 是“坏”提交，A 和 D 是某些“好”提交的父级：

这将得到：

3) 为每个提交关联：min(X, N - X)

其中 X 是步骤 2) 中与提交关联的值，N 是图中提交的总数。

在上述示例中，我们有 N = 8，所以这将得到：

4) 最佳二分查找点是关联值最高的提交。

因此在上述示例中，最佳二分查找点是提交 C。

5) 请注意，为加快算法速度，已实现了一些快捷方式。

由于我们从一开始就知道 N，所以我们知道 min(X, N - X) 不可能大于 N/2。因此，在步骤 2) 和 3) 中，如果我们将 N/2 关联到一个提交，那么我们知道这就是最佳二分查找点。在这种情况下，我们可以停止处理任何其他提交并返回当前提交。

对于任何提交图，您可以使用“git rev-list --bisect-all”来查看每个提交关联的数字。

例如，对于上述图，像这样的命令：

将输出类似以下内容：

首先，我们来定义“最佳二分查找点”。如果知道提交 X 的状态（“好”或“坏”）能提供尽可能多的信息，无论该提交的状态是“好”还是“坏”，我们都称提交 X 为最佳二分查找点或最佳二分查找提交。

这意味着最佳二分查找提交是以下函数值最大的那些提交：

其中 information_if_good(X) 是当 X 为好时我们获得的信息，information_if_bad(X) 是当 X 为坏时我们获得的信息。

现在我们假设只有一个“第一个坏提交”。这意味着它的所有后代都是“坏”的，所有其他提交都是“好”的。我们还假设所有提交是好是坏或成为第一个坏提交的概率相等，因此无论这 c 个提交在图中的哪个位置以及 c 是多少，知道这 c 个提交的状态总是提供相同数量的信息。（因此我们假设这些提交位于分支上或靠近好/坏提交并不会提供更多或更少的信息）。

我们还假设我们有一个经过清理的图，就像上面二分查找算法中步骤 1) 之后的那样。这意味着我们可以根据能够从图中移除的提交数量来衡量我们获得的信息。

让我们取图中一个提交 X。

如果 X 被发现是“好”的，那么我们知道它的所有祖先都是“好”的，所以我们想说：

这是正确的，因为在步骤 1) b) 中，我们移除了“好”提交的祖先。

如果 X 被发现是“坏”的，那么我们知道它的所有后代都是“坏”的，所以我们想说：

但这这是错误的，因为在步骤 1) a) 中，我们只保留了坏提交的祖先。因此，当一个提交被标记为“坏”时，我们获得了更多的信息，因为我们还知道，前一个“坏”提交的祖先（但不是新的“坏”提交的祖先）不是第一个坏提交。我们不知道它们是好是坏，但我们知道它们不是第一个坏提交，因为它们不是新的“坏”提交的祖先。

因此，当一个提交被标记为“坏”时，我们知道可以移除图中除新“坏”提交的祖先之外的所有提交。这意味着：

其中 N 是（清理后的）图中提交的数量。

因此，最终这意味着为了找到最佳二分查找提交，我们应该最大化函数：

这很好，因为在步骤 2) 中我们计算了 number_of_ancestors(X)，因此在步骤 3) 中我们计算了 f(X)。

让我们以下图为例：

如果我们在此图上计算以下非最优函数：

我们得到：

但使用 git bisect 算法，我们得到：

因此我们选择 G、H、K 或 L 作为最佳二分查找点，这比 F 更好。因为如果例如 L 是坏的，那么我们不仅会知道 L、M 和 N 是坏的，还会知道 G、H、I 和 J 不是第一个坏提交（因为我们假设只有一个第一个坏提交，并且它必须是 L 的祖先）。

因此，考虑到我们最初的假设，当前算法似乎是最佳选择。

当某些提交被跳过（使用“git bisect skip”）时，二分查找算法的步骤 1) 到 3) 保持不变。但之后我们大致使用以下步骤：

6) 按关联值递减的顺序对提交进行排序。

7) 如果第一个提交未被跳过，我们可以返回它并在此停止。

8) 否则，在已排序的列表中过滤掉所有已跳过的提交。

9) 使用伪随机数生成器 (PRNG) 生成一个介于 0 和 1 之间的随机数。

10) 将此随机数乘以其平方根，使其偏向 0。

11) 将结果乘以过滤列表中提交的数量，以获得此列表中的索引。

12) 返回计算索引处的提交。

在步骤 7) 之后（在跳过算法中），我们可以检查第二个提交是否已被跳过，如果未被跳过则返回它。实际上，这就是我们从 Git 1.5.4 版本（2008 年 2 月 1 日发布）开发“git bisect skip”以来直到 Git 1.6.4 版本（2009 年 7 月 29 日发布）所使用的算法。

但 Ingo Molnar 和 H. Peter Anvin（另一位著名的 Linux 内核开发者）都抱怨说，有时最佳二分查找点都恰好位于一个所有提交都无法测试的区域。在这种情况下，用户被要求测试许多无法测试的提交，这可能非常低效。

确实，无法测试的提交通常是因为某个时候引入了破坏性变更，而这种破坏性变更只有在引入许多其他提交之后才得到修复。

这种破坏性变更当然大多数时候与我们试图在提交图中定位的破坏性变更无关。但它阻止了我们了解是否存在有趣的“不良行为”。

因此，靠近无法测试的提交的提交本身也很有可能无法测试。而且最佳二分查找提交也常常同时被找到（由于二分查找算法）。

这就是为什么当第一个最佳未跳过二分查找提交已被跳过时，仅仅选择下一个最佳未跳过二分查找提交是个坏主意。

我们发现图中大多数提交在测试时可能会提供相当多的信息。而那些平均不会提供太多信息的提交是靠近好提交和坏提交的那些。

因此，使用一个偏向于远离好提交和坏提交的 PRNG 似乎是一个不错的选择。

对该算法的一个明显改进是，在使用 PRNG 之前，先寻找一个与最佳二分查找提交具有相似关联值且位于另一个分支上的提交。因为如果存在这样的提交，那么它也不太可能无法测试，因此它可能会提供比几乎随机选择的提交更多的信息。

二分查找算法中还有另一个调整，在上面的“二分查找算法”中没有描述。

我们在之前的示例中假设“好”提交是“坏”提交的祖先。但这并不是“git bisect”的要求。

当然，“坏”提交不能是“好”提交的祖先，因为“好”提交的祖先应该都是“好”的。而且所有“好”提交都必须与“坏”提交相关。它们不能位于与“坏”提交分支没有链接的分支上。但一个“好”提交可能与一个“坏”提交相关，但既不是其祖先也不是其后代。

例如，可能有一个“main”分支，以及一个从主分支在名为“D”的提交处派生出来的“dev”分支，像这样：

提交“D”被称为“main”和“dev”分支的“合并基础”，因为它是这些分支进行合并的最佳共同祖先。

现在假设提交 J 是坏的，提交 G 是好的，并且我们应用前面描述的二分查找算法。

如二分查找算法步骤 1) b) 中所述，我们删除所有好提交的祖先，因为它们也应该被认为是好的。

因此，我们将只剩下：

但如果第一个坏提交是“B”，并且它已在“main”分支中通过提交“F”修复，会发生什么？

这样二分查找的结果是我们会发现 H 是第一个坏提交，而实际上它是 B。所以这将是错误的！

事实上，在实践中，在一个分支上工作的人可能并不知道在另一个分支上工作的人已经修复了一个错误！也可能 F 修复了多个错误，或者它是一个尚未准备好发布的重大开发工作的回滚。

事实上，开发团队通常同时维护开发分支和维护分支，如果当他们想在开发分支上二分查找一个维护分支上不存在的回归时，“git bisect”能够直接工作，那对他们来说会非常容易。他们应该能够使用以下方式开始二分查找：

为了启用这个额外的良好功能，当开始二分查找并且某些好提交不是坏提交的祖先时，我们首先计算坏提交和好提交之间的合并基础，并选择这些合并基础作为将要检出和测试的第一个提交。

如果碰巧某个合并基础是坏的，那么二分查找过程将停止并显示类似以下消息：

其中 BBBBBB 是坏合并基础的 SHA1 哈希值，[GGGGGG,…​] 是好提交的 SHA1 哈希值逗号分隔列表。

如果跳过了一些合并基础，二分查找过程会继续，但会为每个跳过的合并基础打印以下消息：

其中 BBBBBB 是坏提交的 SHA1 哈希值，MMMMMM 是被跳过的合并基础的 SHA1 哈希值，[GGGGGG,…​] 是好提交的 SHA1 哈希值逗号分隔列表。

因此，如果没有坏合并基础，二分查找过程在此步骤之后照常进行。

如果您既有测试套件又使用 git bisect，那么在每次提交后检查所有测试是否通过就不那么重要了。当然，进行一些检查以避免破坏太多东西可能仍然是个好主意，因为这可能会使二分查找其他错误变得更加困难。

您可以将精力集中在几个点（例如 rc 和 beta 版本）来检查所有 N 种配置的 T 个测试用例是否都通过。当某些测试不通过时，您可以使用“git bisect”（或更好的“git bisect run”）。因此，您应该大致执行：

其中 c 是测试轮次（因此是一个小常数），b 是每次提交的错误率（希望也是一个小常数）。

因此，当然要好得多，因为它避免了每次提交后测试所有内容所产生的 O(N * T * M) 开销，而只需 O(N * T)。

这意味着测试套件擅长阻止一些错误被提交，并且也能很好地告诉您存在一些错误。但它们在告诉您错误是在何处引入方面表现不佳。要高效地做到这一点，就需要 git bisect。

测试套件的另一个好处是，当您拥有一个测试套件时，您已经知道如何测试不良行为。因此，当出现回归时，您可以使用这些知识为“git bisect”创建一个新的测试用例。这样，二分查找错误并修复它将变得更容易。然后您可以将刚创建的测试用例添加到您的测试套件中。

因此，如果您知道如何创建测试用例以及如何进行二分查找，您将进入一个良性循环：

更多测试 ⇒ 更易创建测试 ⇒ 更易二分查找 ⇒ 更多测试

因此，测试套件和“git bisect”是互补的工具，结合使用时非常强大和高效。

您可以非常轻松地自动二分查找损坏的构建，使用类似以下命令：

例如

另一方面，如果您经常这样做，那么准备脚本以避免过多输入会很值得。

这是一个示例脚本，它经过 Junio Hamano 使用的真实世界脚本 [4] 稍加修改而来。

这个脚本可以传递给“git bisect run”来查找引入性能回归的提交：

显然，不提交已知会破坏事物的更改是个好主意，即使后续有其他提交修复了这些破坏。

在任何 VCS 中，每个提交只包含一个小的逻辑更改也是个好主意。

您的提交中的更改越小，“git bisect”就越有效。而且您最初可能也更少需要“git bisect”，因为即使只由提交者审查，小更改也更容易审查。

另一个好主意是编写良好的提交信息。它们对于理解为什么进行某些更改非常有帮助。

如果您经常进行二分查找，这些一般最佳实践会非常有帮助。

首先，合并本身就可能引入一些回归，即使合并不需要源代码冲突解决。这是因为在一个分支中可能发生语义更改，而另一个分支对此并不知情。

例如，一个分支可能改变一个函数的语义，而另一个分支则增加对同一函数的更多调用。

如果需要修改许多文件来解决冲突，情况会变得更糟。这就是为什么这类合并被称为“邪恶合并”。它们会使回归很难追踪。如果第一个坏提交恰好是这样的合并，甚至可能会产生误导，因为人们可能会认为错误源于糟糕的冲突解决，而实际上它源于一个分支中的语义更改。

无论如何，“git rebase”可以用来线性化历史。这可以用于首先避免合并。或者，在出现一个分支中的语义更改时，它也可以用于在线性历史而不是非线性历史中进行二分查找，因为这应该会提供更多信息。

通过使用更小的分支或使用多个主题分支而不是仅使用与长版本相关的分支，可以使合并更简单。

并且在像 Linux 内核的 linux-next 这样的特殊集成分支中可以更频繁地进行测试。

处理回归的特殊工作流程可以带来很好的结果。

以下是 Andreas Ericsson 使用的一个工作流程示例：

以下是 Andreas 对此工作流程的评价 [5]：

显然，这个工作流程利用了测试套件和“git bisect”之间的良性循环。事实上，它使其成为处理回归的标准程序。

在其他消息中，Andreas 表示他们也使用了上述“最佳实践”：小的逻辑提交、主题分支、无邪恶合并等。这些实践都通过使二分查找更容易、更有用，从而提高了提交图的可二分性。

因此，一个好的工作流程应该围绕上述几点来设计。即，使二分查找更容易、更有用且标准化。

“git bisect”的一个优点是它不仅是一个开发人员工具。它也可以被 QA 人员甚至最终用户有效使用（如果他们可以访问源代码或可以访问所有构建）。

Linux 内核邮件列表上曾有过一次讨论，关于是否可以总是要求最终用户进行二分查找，并且提出了非常好的观点来支持这种做法是可行的。

例如，David Miller 写道 [6]：

这意味着如果 QA 人员或最终用户能够完成，通常会“更便宜”。

另一个有趣之处是，报告错误的最终用户（或重现错误的 QA 人员）可以访问错误发生的环境。因此，他们通常更容易重现回归。如果他们能够进行二分查找，那么将从错误发生的环境中提取更多信息，这意味着将更容易理解并修复该错误。

对于开源项目来说，这可以是获得最终用户更多有用贡献，并将他们引入 QA 和开发活动的好方法。

在某些情况下，例如内核开发，开发复杂的脚本以完全自动化二分查找是值得的。

以下是 Ingo Molnar 对此的看法 [7]：

我们已经看到，测试套件和 git bisect 结合使用时非常强大。如果能将它们与其他系统结合，则会更加强大。

例如，一些测试套件可以在夜间自动运行，采用一些不寻常（甚至随机）的配置。如果测试套件发现回归，“git bisect”可以自动启动，其结果可以电子邮件发送给“git bisect”发现的第一个坏提交的作者，也许还可以发送给其他人。并且，缺陷跟踪系统中也可以自动创建一个新条目。

我们之前看到，“git bisect skip”现在使用 PRNG 试图避免提交图中存在无法测试提交的区域。问题在于，有时第一个坏提交会位于一个无法测试的区域。

为了简化讨论，我们假设无法测试的区域是一串简单的提交，并且它是由一个提交（我们称之为 BBC，二分查找破坏提交）引入的破坏造成的，后来又由另一个提交（我们称之为 BFC，二分查找修复提交）修复。

例如

其中我们知道 Y 是好的，BFC 是坏的，而 BBC 和 X1 到 X6 是无法测试的。

在这种情况下，如果您手动进行二分查找，您可以创建一个特殊分支，该分支恰好在 BBC 之前开始。该分支中的第一个提交应该是将 BFC 合并到 BBC 中。而该分支中的其他提交应该是 BBC 和 BFC 之间的提交，它们都基于该分支的第一个提交进行变基，然后 BFC 之后的提交也进行变基。

例如

其中带 ' 引号的提交已进行变基。

您可以使用 Git 的交互式变基轻松创建这样的分支。

例如，使用：

然后将 BFC 移到 BBC 之后并压缩它。

之后，您可以在新分支中照常开始二分查找，并最终找到第一个坏提交。

例如

如果您正在使用“git bisect run”，您可以像上面一样进行手动修复，然后在这个特殊分支中开始另一个“git bisect run”。或者，正如“git bisect”手册页所说，传递给“git bisect run”的脚本可以在编译和测试软件之前应用一个补丁 [8]。该补丁应该将当前无法测试的提交转换为可测试的提交。这样测试结果将是“好”或“坏”，并且“git bisect”将能够找到第一个坏提交。脚本在退出之前，不应忘记在测试完成后移除补丁。

（请注意，除了补丁之外，您还可以使用“git cherry-pick BFC”来应用修复；在这种情况下，您应该在测试后且在脚本返回之前，使用“git reset --hard HEAD^”来撤销 cherry-pick。）

但以上规避无法测试区域的方法有点笨拙。使用特殊分支很好，因为这些分支可以像普通分支一样在开发人员之间共享，但风险是人们会创建很多这样的分支。而且它会扰乱正常的“git bisect”工作流程。因此，如果您想完全自动地使用“git bisect run”，您必须在脚本中添加特殊代码以在特殊分支中重新启动二分查找。

无论如何，在上面的特殊分支示例中，我们可以注意到 Z' 和 Z 提交应该指向相同的源代码状态（在 git 术语中是相同的“树”）。这是因为 Z' 是将与 Z 相同的更改以略微不同的顺序应用而产生的。

因此，如果我们在二分查找时能够简单地用 Z' “替换” Z，那么我们就无需向脚本中添加任何东西。对于项目中共享特殊分支和替换的任何人来说，它都能正常工作。

结合上面的例子，将得到：

这就是创建“git replace”命令的原因。技术上，它将替换“引用”（refs）存储在“refs/replace/”层次结构中。这些“引用”类似于分支（存储在“refs/heads/”中）或标签（存储在“refs/tags/”中），这意味着它们可以像分支或标签一样在开发人员之间自动共享。

“git replace”是一个非常强大的机制。它可以用于修复已发布历史中的提交，例如更改提交信息或作者。它也可以用来代替 git “grafts”来将一个仓库与另一个旧仓库链接。

事实上，正是这个最后的功能让它“推销”给了 Git 社区，因此它现在位于 Git 仓库的“master”分支中，并预计在 2009 年 10 月或 11 月的 Git 1.6.5 版本中发布。

“git replace”的一个问题是，目前它将所有替换引用存储在“refs/replace/”中，但如果仅用于二分查找的替换引用存储在“refs/replace/bisect/”中可能会更好。这样，替换引用就可以仅用于二分查找，而“refs/replace/”中的其他引用则几乎一直使用。

“git bisect”的另一个可能改进是可选地增加所执行测试的冗余，以便在追踪偶发性错误时更加可靠。

一些内核开发者曾提出此要求，因为某些被称为偶发性错误的 bug 并非出现在所有内核构建中，因为它们非常依赖于编译器输出。

这个想法是，例如每进行 3 次测试，“git bisect”就可以要求用户测试一个已经被发现是“好”或“坏”的提交（因为它的某个后代或祖先分别被发现是“好”或“坏”）。如果发现某个提交之前被错误分类，那么二分查找可以提前中止，希望在犯下太多错误之前。然后用户必须查看发生了什么，然后使用修正后的二分查找日志重新启动二分查找。

GitHub 上已有一个由 Ealdwulf Wuffinga 创建名为 BBChop 的项目，它利用贝叶斯搜索理论实现了类似的功能 [9]：

但 BBChop 独立于任何 VCS，对于 Git 用户来说，拥有集成在 Git 中的功能会更容易。