29

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

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

为了测试这种行为,我必须运行我的脚本dependent.pl。但是当 bisect 跳转到代码的一半时,我的脚本在 Master 上不存在,因此无法测试。

我相信这是因为 bisect 将您拉入无头状态,但在这种情况下,我真的想处于另一个历史/变更集的上下文中,而不是漂浮在以太中。

在任何人跳到你做错了蜂鸣器之前,我们的团队喜欢在这些情况下合并分支,因为这个比喻适用于这种情况,而不是变基。

我将通过创建一个示例 repo 来演示这个:

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 上的提交破坏了它,所以我不能说这个提交是好是坏。

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

4

1 回答 1

32

这里的问题是 git bisect分支感知的。当你告诉它“依赖”是好的而“测试”是坏的,并且其中一个变化是合并提交时,它知道为了找出问题是在哪里引入的,它必须查看提交 a、b 和 c - 否则,它只能告诉你它是否在合并提交时被破坏。

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

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

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

于 2010-09-09T02:42:33.943 回答