我有一个带有复杂的分支和合并树的存储库，我想使用 git bisect 来查找引入错误的时间。
我有一个好的提交和坏的提交来开始二等分，其中好的提交是坏提交的祖先。
我希望git bisect提交具有良好提交作为祖先的提交，但它没有（使用 git 2.21.0）。
目前，我通过保留提交列表并git rev-list --ancestry-path GOOD..BAD在中间使用和选择提交来手动进行二等分。有没有办法让这个自动化git bisect？它是否有旗帜可以留在祖先的道路上？
与正在搜索的错误相关的功能可能并非在所有分支中都存在，因此检查在那里无关紧要。不过，它们应该存在于祖先路径中。
一旦完成了对祖先路径的二等分，一个人可能会得到一个合并提交作为罪魁祸首，他们就会知道这个错误来自那个分支。这已经教会了人们很多关于这个错误的知识。
为了继续对引入 bug 的分支进行二等分，不需要单独测试每个提交（因为它们不一定具有使 bug 出现所需的特性），但应该将每个提交与最后一个好的提交合并然后检查错误是否存在。然后可以查明特定的提交，当与好的提交合并时，会引入错误。
请注意，我已经多次执行此过程，它对我非常有用，我只是在寻找使其更方便的方法。
假设我突然发现我的Git回购失败了.但我知道它在几个提交之前工作,我只是不记得哪个提交.我想问Git(可能带有bash脚本),而不是试图找到一个"好"的提交来做一个git bisect,最近的"好"提交是什么？
另一个原因是不要只是暂时选择一个提交并将其用作好的,因为在我的repo中有很多糟糕和好的提交混合在一起.这不是线性的.
那么我怎么能循环,从最近的提交开始,并且只要有必要,执行一个返回1的命令,如果错误0则返回1？
理解Git Workflow文章说,
因此,您添加了一条新规则:"当您在功能分支中合并时,请使用-no-ff强制执行新提交."这样可以完成工作,然后继续.
然后有一天你发现了生产中的一个关键错误,你需要追踪它何时被引入.你运行bisect但继续登陆检查点提交.你放弃并手工调查.
您将错误缩小到单个文件.在过去的48小时里,你一直负责看看它是如何变化的.你知道这是不可能的,但是责备报告文件在几周内没有被触及.事实证明,责备报告了初始提交时间的变化,而不是合并时的变化.您的第一个检查点提交在几周前修改了此文件,但此更改已于今天合并.
没有ff的创可贴,破碎的二等分和责备神秘都是你用螺丝刀作为锤子的症状.
--no-ff当您明确阻止快进合并时,git merge 就是一种情况.但是,如果一个提交不是另一个提交的直接祖先,那么快进甚至不会发生.这是一个罕见的开发方案.换句话说,大多数合并都是非快进类型.那么如何通过--no-ff打破的功能bisect和blame？
我在一个单独的分支上redesign-test-fixes,我跑了git bisect start.在那之后,我测试我的bug并运行git bisect bad.终端打印无输出.然后我跑了git bisect good.同样的事情,终端上没有打印输出.就像bisect一开始没有运行一样.通常我希望终端输出有关剩余步数的信息.怎么了？怎么解决这个问题？我是否处于一种不允许我运行bisect的git状态.
git状态响应:
On branch redesign-test-fixes
nothing to commit, working directory clean
但是,如果我运行git bisect startgit status响应:
On branch redesign-test-fixes
You are currently bisecting, started from branch 'redesign-test-fixes'.
(use "git bisect reset" to get back to the original branch)
nothing to commit, working directory clean
在某些情况下,在git bisect会话期间,测试特定的提交需要很长时间(例如,因为我必须构建一个完整的发行包并将其部署在一个特别奇怪的机器上).实际上,测试构建需要很长时间,以至于我想在不知道当前测试是否成功的情况下开始构建接下来的两个提交.这样,我可以通过测试当前版本并并行构建接下来的两个版本来加速二等分.
有没有人知道如何git bisect显示接下来的两个版本,具体取决于当前提交是好还是坏？
尝试使用以下命令开始二等分，
git bisect start
导致 Git 响应：
fatal: invalid reference: atrium-3018
这是什么原因，我该如何解决？
假设我正在执行git bisect，并且在运行git bisect bad命令后，我的git bisect会像这样被打断：
$ git bisect bad
Bisecting: 0 revisions left to test after this (roughly 1 step)
error: Your local changes to the following files would be overwritten by checkout:
app/app.iml
Please commit your changes or stash them before you switch branches.
Aborting
我可以通过运行以下命令消除该文件：
git checkout -- app/app.iml
这将使我的git的状态下，再次清洁..但我不知道如何继续以后（即让git的开张继续平分）。我相信，我已经做了git bisect bad之前和它种跳过一个台阶或做了一件我没想到。我只是想恢复我的git bisect操作..该怎么做？
我开始git bisect会话时的常用工作流程是:
git bisect start # start a bisect session
git bisect bad # I noticed that the current state is broken
现在,我经常知道过去的事情是有效的,但我不知道哪个版本是好的,所以我通常想把我的工作树恢复到较旧的状态,构建,测试,重复直到我找到一个工作版本我可以用git bisect good.
什么是"将我的工作树恢复到较旧状态"步骤的最佳方法？git reset --hard <some_good_rev>？git checkout <some_good_rev>？别的什么？请证明你的答案.
在git中，我们必须bisect方便地找到第一个错误的提交，这样：
git bisect start linux-next/master v2.6.26-rc8
git bisect run make kernel/fork.o
但前提是我知道哪个旧的提交是好的。在此示例中，它是 v2.6.26-rc8。
如果我不知道哪个提交是好的，会发生什么？
是否可以编写一个脚本，反向循环 git 提交，从当前 HEAD 开始，从最新到最旧，并自动测试每个提交，直到第一个好？
在长期项目中，可能会有一大堆提交，在二分期间不值得尝试，例如
第二个大部分可以通过使用来处理，bisect --first-parent尽管它需要记住使用它，但第一个是更多的问题。
的脚本bisect run可以提供该功能，但它需要是一个元脚本，它要么运行子脚本（针对这种情况），要么充当 shell，在应包含提交时bisect run采用old//命令来传递new它们。skip