我试图找到自过去一天在一个名为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 上的提交破坏了它，所以我不能说这个提交是好是坏。
我如何测试是什么破坏了我当前的分支？