git-bisect - 云端在线

程序：

您的姓名

git-bisect - 使用二进制搜索查找引入错误的提交

概要

混帐 二等分

商品描述

该命令采用各种子命令，并根据子命令使用不同的选项：

git bisect start [--term-{old,good}= --term-{new,bad}= ]
[--不结帐] [ [ ...]] [--] [ ...]
git bisect (坏|新) [ ]
git bisect (good|old) [ ...]
git 平分条款 [--term-good | --term-坏]
git 平分跳过 [( | )...]
git 平分重置 [ ]
git bisect 可视化
git 平分重放
git 平分日志
git 平分运行...
git 平分帮助

此命令使用二进制搜索算法来查找项目历史记录中的哪个提交
引入了一个错误。 您通过首先告诉它一个已知包含的“坏”提交来使用它
错误，以及在引入错误之前已知的“良好”提交。 然后 git
bisect 在这两个端点之间选择一个提交并询问您是否选择了提交
是“好”还是“坏”。 它继续缩小范围，直到找到确切的提交
这引入了变化。

事实上，git bisect 可以用来查找发生变化的提交 任何 你的财产
项目; 例如，修复错误的提交，或导致基准测试的提交
性能有待提高。 为了支持这种更普遍的用法，术语“旧”和“新”可以
用于代替“好”和“坏”，或者您可以选择自己的术语。 见部分
更多信息请参见下方的“替代术语”。

基础版 二等分 命令： 开始， 坏的， 非常好
举个例子，假设你试图找到破坏了一个特性的提交
已知可在您的项目的 v2.6.13-rc2 版本中使用。 你开始一个二等分会话
如下：

$ git 平分开始
$ git bisect bad # 当前版本不好
$ git bisect good v2.6.13-rc2 # v2.6.13-rc2 已知是好的

一旦你指定了至少一个坏的和一个好的提交，git bisect 就会选择一个提交
在该历史范围的中间，检查它，并输出类似于
执行以下操作：

一分为二：在此之后还有 675 个修订版需要测试（大约 10 个步骤）

您现在应该编译已检出的版本并对其进行测试。 如果那个版本有效
正确，输入

$ git 平分好

如果该版本已损坏，请键入

$ git 平分坏

然后 git bisect 将响应类似

一分为二：在此之后还有 337 个修订版需要测试（大约 9 个步骤）

不断重复这个过程：编译树，测试它，并取决于它是否好
or bad 运行 git bisect good 或 git bisect bad 来请求下一次需要的提交
测试。

最终将没有更多的修订要检查，并且命令将打印出来
第一次错误提交的描述。 参考 refs/bisect/bad 将被左指向
在那个提交。

一分为二 重置
平分会话后，要清理平分状态并返回原始 HEAD，
发出以下命令：

$ git 平分重置

默认情况下，这会将您的树返回到在 git 之前签出的提交
平分开始。 （一个新的 git bisect start 也会这样做，因为它会清理旧的二等分
状态。）

使用可选参数，您可以改为返回不同的提交：

$ git 平分重置

例如， git bisect reset bisect/bad 将检查第一个错误的修订版，而 git
bisect reset HEAD 会让你停留在当前的二分提交上并避免切换
完全提交。

备用 条款
有时您不是在寻找引入破坏的提交，而是在寻找
导致其他“旧”状态和“新”状态之间发生变化的提交。 例如，
您可能正在寻找引入特定修复程序的提交。 或者你可能是
寻找源代码文件名最终全部转换的第一次提交
符合贵公司的命名标准。 管他呢。

在这种情况下，使用术语“好”和“坏”来指代“
更改前的状态”和“更改后的状态”。因此，您可以使用
分别用“旧”和“新”来代替“好”和“坏”。 （但请注意，您
不能在一次会话中将“好”和“坏”与“旧”和“新”混在一起。）

在这个更一般的用法中，您提供 git bisect 与“新”提交有一些属性
以及没有该属性的“旧”提交。 每次 git bisect 检查一个
提交，您测试该提交是否具有该属性。 如果是，将提交标记为“新”；
否则，将其标记为“旧”。 等分完成后， git bisect 将报告哪个
commit 引入了属性。

要使用“旧”和“新”而不是“好”和“坏”，您必须运行 git bisect start 而不使用
commits 作为参数，然后运行以下命令来添加提交：

git 平分旧 [ ]

表明提交是在寻求更改之前，或

git 平分新 [ ...]

表明它是在之后。

要获得当前使用的术语的提醒，请使用

git 平分项

您可以使用 git bisect term --term-old 或 git 获得旧的（分别是新的）术语
平分项 --term-good。

如果您想使用自己的术语而不是“坏”/“好”或“新”/“旧”，您可以
选择您喜欢的任何名称（除了现有的 bisect 子命令，如 reset、start、...）
开始二分使用

git bisect start --term-old --新学期

例如，如果您正在寻找引入性能回归的提交，您
可能会用

git bisect start --term-old 快 --term-new 慢

或者，如果您正在寻找修复错误的提交，您可以使用

git bisect start --term-new 固定 --term-old 坏了

然后，使用 git bisect 和 git 平分而不是 git bisect 好和
git bisect bad 标记提交。

一分为二 想像
查看当前剩余的嫌疑人 吉特克, 在执行过程中发出以下命令
对分过程：

$ git bisect 可视化

视图也可以用作可视化的同义词。

如果 显示屏玻璃制造 未设置环境变量， 混帐 日志 改为使用。 你也可以给
命令行选项，例如 -p 和 --stat。

$ git 平分视图 --stat

一分为二 日志 和 二等分 重播
将修订标记为好或坏后，发出以下命令以显示已修改的内容
到目前为止已完成：

$ git 平分日志

如果您发现在指定修订状态时犯了错误，您可以
将此命令的输出保存到文件中，对其进行编辑以删除不正确的条目，然后
然后发出以下命令以返回到正确的状态：

$ git 平分重置
$ git bisect 重放那个文件

避免 测试 a 承诺
如果在二等分会议的中间，您知道建议的修订是不好的
一个来测试（例如它无法构建并且您知道失败没有任何内容
与您正在追逐的错误有关），您可以手动选择附近的提交并测试
一个代替。

例如：

$ git bisect good/bad # 前一轮是好是坏。
一分为二：在此之后还有 337 个修订版需要测试（大约 9 个步骤）
$ git bisect visual # 哎呀，没意思。
$ git reset --hard HEAD~3 # 在什么之前尝试 3 次修订
# 被建议

然后编译并测试所选的修订版，然后将修订版标记为好或坏
以通常的方式。

一分为二 跳过
你可以让 Git 为你做，而不是自己选择附近的提交
发出命令：

$ git bisect skip # 当前版本无法测试

但是，如果您跳过与您要查找的提交相邻的提交，Git 将无法
确切地说出哪些提交是第一个错误的。

您还可以使用范围表示法跳过一系列提交，而不仅仅是一次提交。
例如：

$ git bisect 跳过 v2.5..v2.6

这告诉 bisect 进程在 v2.5 之后没有提交，直到并包括 v2.6，应该
进行测试。

请注意，如果您还想跳过该范围的第一次提交，您将发出
命令：

$ git bisect 跳过 v2.5 v2.5..v2.6

这告诉 bisect 进程 v2.5 和 v2.6（包括）之间的提交应该是
跳过。

分切 向下 对分 by 给予 更多 参数 至 二等分 开始
如果您知道树的哪一部分，您可以进一步减少试验次数
通过在发出时指定路径参数，涉及到您正在追踪的问题
平分启动命令：

$ git bisect start --arch/i386 包含/asm-i386

如果你事先知道不止一个好的提交，你可以缩小二等分空间
在发出错误提交后立即指定所有好的提交
平分启动命令：

$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 --
# v2.6.20-rc6 不好
# v2.6.20-rc4 和 v2.6.20-rc1 都不错

一分为二 运行
如果你有一个脚本可以判断当前的源代码是好是坏，你可以
通过发出命令来平分：

$ git bisect 运行 my_script 参数

注意脚本（上面例子中的 my_script）应该以代码 0 退出
当前源代码是好的/旧的，并以 1 到 127（含）之间的代码退出，
除了 125，如果当前的源代码是坏的/新的。

任何其他退出代码都将中止二等分过程。 应该指出的是，一个程序
通过 exit(-1) 终止离开 $? = 255，（见 出口(3) 手册页），因为值为
用 & 0377 切碎。

当无法测试当前源代码时，应使用特殊退出代码 125。 如果
脚本使用此代码退出，当前版本将被跳过（参见 git bisect skip
以上）。 125 被选为用于此目的的最高合理值，因为 126
和 127 被 POSIX shell 用来表示特定的错误状态（127 用于命令而不是
found, 126 表示找到的命令但不可执行——这些细节无关紧要，因为它们
就 bisect run 而言，是脚本中的正常错误）。

您可能经常发现在 bisect 会话期间您想要临时修改
（例如，头文件中的 s/#define DEBUG 0/#define DEBUG 1/，或“没有
这个提交需要应用这个补丁来解决这个二分不是的另一个问题
感兴趣") 应用于正在测试的修订版。

应对这样的情况，经过内在 混帐 二等分 找到下一个要测试的修订版，
脚本可以在编译前应用补丁，运行真正的测试，然后决定
如果修订版（可能带有所需的补丁）通过测试，然后倒带树
到原始状态。 最后，脚本应该以实际测试的状态退出
让 git bisect run 命令循环确定 bisect 会话的最终结果。

配置

--无结帐
不要在二分过程的每次迭代中检查新的工作树。
而只是更新一个名为的特殊引用 BISECT_HEAD 使其指向
应该测试的提交。

当您在每个步骤中执行的测试没有
需要一个检出的树。

如果存储库是空的，则假定 --no-checkout。

示例

· 在 v1.2 和 HEAD 之间自动平分一个损坏的构建：

$ git bisect start HEAD v1.2 -- # HEAD 不好，v1.2 好
$ git bisect run make # "make" 构建应用
$ git bisect reset # 退出 bisect 会话

· 自动平分原点和 HEAD 之间的测试失败：

$ git bisect start HEAD origin -- # HEAD 不好，起源好
$ git bisect run make test # "make test" 构建和测试
$ git bisect reset # 退出 bisect 会话

· 自动平分一个损坏的测试用例：

$猫 ~/测试.sh
#!/ bin / sh的
使|| exit 125 # 这会跳过损坏的构建
〜/ check_test_case.sh # 测试用例通过了吗？
$ git bisect start HEAD HEAD~10 -- # 罪魁祸首是最后 10 个
$ git 平分运行 ~/测试.sh
$ git bisect reset # 退出 bisect 会话

这里我们使用 test.sh 自定义脚本。 在这个脚本中，如果 make 失败，我们跳过
当前提交。 如果测试用例通过，check_test_case.sh 应该退出 0，并退出 1
除此以外。

如果 test.sh 和 check_test_case.sh 都在存储库之外，则更安全
防止 bisect、make 和 test 过程与脚本之间的交互。

· 自动平分临时修改（热修复）：

$猫 ~/测试.sh
#!/ bin / sh的

# 通过合并热修复分支来调整工作树
# 然后尝试构建
如果 git merge --no-commit hot-fix &&
使
然后
# 运行项目特定的测试并报告其状态
〜/ check_test_case.sh
状态=$？
其他
# 告诉调用者这是不可测试的
状态=125
fi

# 撤消调整以允许干净地翻转到下一次提交
git 重置 --hard

# 返回控制
退出 $status

这会在每次测试运行之前应用来自修补程序分支的修改，例如
您的构建或测试环境发生了变化，因此旧版本可能需要修复
较新的已经。 （确保热修复分支基于提交
包含在您要平分的所有修订中，以便合并不会引入
太多，或者使用 git cherry-pick 而不是 git merge。）

· 自动平分一个损坏的测试用例：

$ git bisect start HEAD HEAD~10 -- # 罪魁祸首是最后 10 个
$ git bisect run sh -c "make || exit 125; 〜/ check_test_case.sh"
$ git bisect reset # 退出 bisect 会话

这表明如果您在单个文件上编写测试，则无需运行脚本即可
线。

· 在损坏的存储库中找到对象图的一个好的区域

$ git bisect start HEAD [ ... ] --no-checkout
$ git bisect run sh -c '
GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) &&
git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ &&
git pack-objects --stdout >/dev/null
rc=$？
rm -f tmp.$$
测试 $rc = 0'

$ git bisect reset # 退出 bisect 会话

在这种情况下 混帐 二等分 运行 完成， bisect/bad 将指的是一个提交
至少一个父级，其可达图在所需的意义上是完全可遍历的
by 混帐 收拾 对象.

· 在代码中寻找修复而不是回归

$ git 平分开始
$ git bisect new HEAD # 当前提交被标记为新的
$ git bisect old HEAD~10 # 从现在开始的第十次提交被标记为旧的

要么：

$ git bisect start --term-old 损坏 --term-new 固定
$ git bisect 固定
$ git bisect 破碎的 HEAD~10

得到 帮助
使用 git bisect 获取简短的使用说明，并使用 git bisect help 或 git bisect -h
获取详细的使用说明。

使用 onworks.net 服务在线使用 git-bisect