git - 为什么 'git bisect' 分支不知道？

Question

我正在尝试查找自从过去一天在名为 feature-x 的长期分支(将在很久以后发布)上提交以来出现的错误的来源。

虽然有一个错误。我发现我的脚本没有预料到的行为可能已经在迄今为止的任何提交中引入，特别是因为 master 的特性在 feature-x 中大量使用，但在 Master 本身上使用得较少。

要测试此行为，我必须运行我的脚本 dependent.pl。但是当 bisect 跳到代码的一半时，我的脚本在 Master 上不存在，所以无法测试。

我相信这是因为 bisect 将你 pull 出到 headless 状态，但在这种情况下，我真的想处于另一个历史/变更集的上下文中，而不是漂浮在以太中。

在任何人跳起来敲响你做错了蜂鸣器之前，我们的团队喜欢在这些情况下 merge 分支，因为这个比喻适用于这种情况，而不是 rebase 。

我将通过创建示例存储库来对此进行演示:

git init

echo 'sub f { print $_; }' > main.pl
git add .
git commit -a -m "inital commit"

git branch feature-x
git checkout feature-x
echo 'main::f(1)' > dependent.pl
git add .
git commit -a -m "Starting work on feature X"
git tag dev-1.0

git checkout master
echo "sub f { return 1; }" > main.pl
git commit -a -m "sub f { return 1; }"
echo "sub f { return 2; }" > main.pl
git commit -a -m "sub f { return 2; }"
echo "sub f { return 3; }" > main.pl
git commit -a -m "sub f { return 3; }"

git tag release-1.0

git checkout feature-x
git merge master

echo 'print main::f();' > dependent.pl
git commit -a -m "Updating call to f"

现在你得到一个看起来像这样的 repo:

o Updating call to f ( Head of branch 'feature-x' )
o Merge branch master onto feature-x
|\
| o sub f { return 3; } (TAG release-1.0) ( Head of branch 'master' )
| o sub f { return 2; }
| o sub f { return 1; }
o | Starting work on feature X ( TAG 'dev-1.0' )
 \|
  o initial commit

所以我运行命令 git bisect start feature-x dev-1.0 希望我能够在 dependent.pl 中找到破坏我的代码的地方，我最终提交了 'sub f { return 2 }' 没有我从 feature-x 更改的历史记录(即，如果我运行 ls，我看到的只是 main.pl 和 dependent.pl 丢失)。

这让我处于无法测试的状态。我不知道当前的提交是否破坏了我的工作，也不能说 master 上的提交破坏了它，所以我不能说这次提交是好是坏。

我如何测试是什么破坏了我当前的分支？

Answer 1

这里的问题是 git bisect 是 分支感知。当您告诉它“dependent”是好的，“test”是坏的，并且其中一个更改是 merge 提交时，它知道为了弄清楚问题是从哪里引入的，它必须查看提交 a、b 和 c - 否则，它只能告诉你它在 merge 提交时是否已损坏。

听起来您期望的是测试提交 b 与来自其他分支的更改的组合，这是任何提交中都不存在的内容，以及 git bisect只让你测试提交!为了测试该内容，您必须进行一系列测试 merge - 检查 b， merge 依赖，让您测试，然后检查 a 或 c， merge 依赖，让您再次测试。你可以很容易地做到git merge --no-commit dependent一旦它离开你在提交 b，然后做 git reset --hard在运行前完成测试 git bisect good/bad .

否则，如果我误解了你希望它不测试 merge 分支上的 任何 提交，而只测试 merge 提交本身(你不关心 a、b 或c 破坏了它)，只需告诉它 merge 分支上的一切都很好。如果您知道 a、b 和 c 与它无关，那就更好了。然后你甚至不用测试就知道它们很好!

但是你无法预料的一件事是 git 会完全忽略提交 a、b 和 c。它绝对无法知道他们的更改是否与您的“错误”相关，并且他们的更改是您的好提交和坏提交之间差异的一部分。