如何使用git bisect？ [英] How to use git bisect?

问题描述

我读过一些文章说 git bisect 很棒，但我不是母语的，我不明白为什么它很棒。

b
$ b

您能否在一些代码示例上演示如此令人惊奇的功能？是否就像 svn blame ？

解决方案

c $ c> git bisect 是在历史记录中执行二进制搜索以找到特定的回归。假设您有以下发展历史：

  ... --- 0 --- 1 --- 2  -  -  3 --- 4 * --- 5 ---当前
  

你知道你的程序是在 current 修订版中无法正常工作，并且它在修订版 0 下工作。因此，回归可能在其中一个提交 1 ， 2 ， 3 ， 4 ， 5 ，当前 。



您可以尝试检查每个提交，构建它，检查回归是否存在。如果有大量提交，这可能需要很长时间。这是一个线性搜索。我们可以做一个二进制搜索更好。这是 git bisect 命令的作用。在每一步，它都会尝试减少可能损坏一半的修订数量。

您将使用如下命令：

  $ git stash save 
 $ git bisect start 
 $ git bisect bad 
 $ git bisect good 0 
 Bisecting ：在此之后剩下两个修订版本（大约两个步骤）
 [< ... sha ...>] 3 
  

执行此命令后， git 将签出一个提交。在我们的例子中，它将是提交 3 。你需要建立你的程序，并检查回归是否存在。如果回归存在，您还需要通过 git bisect bad 来告诉 git 此版本的状态，或 git bisect good 如果不是。

假设回归是在commit <$ c $中引入的C> 4 。然后在这次修订中不会出现回归，我们将它告诉 git 。

  $ make 
 $ make测试
 ... ... ... 
 $ git bisect good 
二等分：剩余0个修订版在此之后进行测试（大致为1步骤）
 [< ... sha ...>] 5 
  

然后它会检出另一个提交。可以是 4 或 5 （因为只有两个提交）。假设它选取了 5 。构建完成后，我们测试程序并查看是否存在回归。然后我们将它告诉 git ：

  $ make 
 $ make test 
 ... ... ... 
 $ git bisect bad 
 Bisecting：在此之后剩下0个修订版本（大概0步）
 [< ... sha ...>] 4 
  

我们测试上一个版本 4 。因为它是引入回归的那个，所以我们将它告诉 git ：

  $ make 
 $ make test 
 ... ... ... 
 $ git bisect bad 
< b< ...沙...>是第一个错误的提交
< ...提交信息...> 
  

在这种简单的情况下，我们只需测试3个版本（ 3 ， 4 ， 5 ）而不是4（ 1 ， 2 ， 3 ， 4 ）。这是一场小胜，但这是因为我们的历史很短暂。如果搜索范围为N个提交，我们应该测试1 + log2 N提交 git bisect ，而不是使用线性搜索进行大约N / 2次提交。





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

I have read some articles saying that git bisect is awesome, however I'm not native speaker and I can't understand why it's awesome.

Could you please demonstrate on some code sample what is so amazing about it? Is it just like svn blame?

解决方案

The idea behind git bisect is to perform a binary search in the history to find a particular regression. Imagine that you have the following development history:

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

You know that your program is not working properly at the current revision, and that it was working at the revision 0. So the regression was likely introduced in one of the commits 1, 2, 3, 4, 5, current.

You could try to check out each commit, build it, check if the regression is present or not. If there is a large number of commits, this can take a long time. This is a linear search. We can do better by doing a binary search. This is what the git bisect command does. At each step it tries to reduce the number of revisions that are potentially bad by half.

You'll use the command like this:

$ 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

After this command, git will checkout a commit. In our case, it'll be commit 3. You need to build your program, and check whether or not the regression is present. You'll also need to tell git the status of this revision with either git bisect bad if the regression is present, or git bisect good if it is not.

Let's suppose that the regression was introduced in commit 4. Then the regression is not present in this revision, and we tell it to git.

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

It will then checkout another commit. Either 4 or 5 (as there are only two commits). Let's suppose it picked 5. After a build we test the program and see that the regression is present. We then tell it to git:

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

We test the last revision, 4. And since it is the one that introduced the regression, we tell it to git:

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

In this simple situation, we only had to test 3 versions (3, 4, 5) instead of 4 (1, 2, 3, 4). This is a small win, but this is because our history is so small. If the search range is of N commits, we should expect to test 1 + log2 N commits with git bisect instead of roughly N / 2 commits with a linear search.

Once you've found the commit that introduced the regression, you can study it to find the issue. Once this is done, you use git bisect reset to put everything back on the original state before using git bisect command.

这篇关于如何使用git bisect？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！