背后的想法git bisect是在历史中执行二进制搜索以找到特定的回归。假设您有以下开发历史：

... --- 0 --- 1 --- 2 --- 3 --- 4* --- 5 --- current

您知道您的程序在修订版中无法正常运行current，并且在修订版中可以正常运行0。所以回归很可能是在其中一个提交中引入的1，2, 3,
4, 5, current.

您可以尝试检查每个提交，构建它，检查是否存在回归。如果有大量提交，这可能需要很长时间。这是一个线性搜索。我们可以通过二分查找做得更好。这就是git bisect命令的作用。在每个步骤中，它都试图将可能不好的修订数量减少一半。

您将使用如下命令：

$ git stash save
$ git bisect start
$ git bisect bad
$ git bisect good 0
Bisecting: 2 revisions left to test after this (roughly 2 steps)
[< ... sha ... >] 3

在此命令之后，git将签出一个提交。在我们的例子中，它将是 commit
3。您需要构建您的程序，并检查是否存在回归。您还需要通过回归是否存在来告知git此修订的状态。git bisect bad``git bisect good

假设在 commit 中引入了回归4。那么这个版本中没有回归，我们告诉它git。

$ make
$ make test
... ... ...
$ git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[< ... sha ... >] 5

然后它将检查另一个提交。要么4或5（因为只有两个提交）。让我们假设它被选中5。在构建之后，我们测试程序并看到回归存在。然后我们告诉它git：

$ make
$ make test
... ... ...
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 0 steps)
[< ... sha ... >] 4

我们测试最后一个版本，4. 由于它是引入回归的那个，我们告诉它git：

$ make
$ make test
... ... ...
$ git bisect bad
< ... sha ... > is the first bad commit
< ... commit message ... >

在这种简单的情况下，我们只需要测试 3 个版本 ( 3, 4, 5) 而不是 4 个 ( 1, 2, 3,
4)。这是一个小小的胜利，但这是因为我们的历史太短了。如果搜索范围是 N 次提交，我们应该期望git bisect使用线性搜索测试 1 + log2
N 次提交，而不是大约 N / 2 次提交。

一旦你找到了引入回归的提交，你就可以研究它来找到问题。完成此操作后，您可以在使用命令git bisect reset之前将所有内容恢复到原始状态。git bisect