我正在尝试找到自过去一天在一个长期存在的分支（将在很久以后发布）上提交以来出现的错误的来源，该分支称为特征-x.
但有一个错误。我发现我的脚本中没有预期的行为，到目前为止，这些行为可能已在任何提交中引入，特别是因为 master 的功能在 feature-x 中大量使用，但在 Master 本身上使用较少。
为了测试此行为，我必须运行我的脚本 dependent.pl。但是，当 bisect 跳转到代码的一半时，我的脚本在 Master 上不存在，因此无法测试。
我相信这是因为 bisect 将你拉入无头状态，但在这种情况下，我真的希望处于其他历史/变更集的背景中，而不是漂浮在以太中。
在任何人跳起来击中之前你这样做是错的蜂鸣器，我们的团队喜欢在这些情况下合并分支，因为这个比喻非常适合这种情况，而不是重新设置基础。
我将通过创建示例存储库来演示这一点：
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"
所以现在你得到一个看起来像这样的存储库：
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 上的提交破坏了它，所以我不能说这个提交是好还是坏。
我如何测试是什么破坏了我当前的分支？
