2

我的目标是使用 git bisect。我受到以下事实的阻碍，即显然接近引入我要纠正的问题的提交，我引入了另一个小错误，导致许多邻居提交无法测试。

这第二个错误是一个微不足道的错误。后来我更正了它几次提交。

我想做的是：

git checkout master
git checkout -b fully-testable-branch
git rebase -i initial-good-bisect-point

然后从提交列表中删除引入第二个错误的提交。我期待并准备好处理代码和历史领域的一些冲突。

然后，如果一切顺利（它应该——这个项目中的大多数提交都是可测试的）我可以再次平分，这次在完全可测试分支的尖端和初始良好平分点之间，找到并研究问题提交，结帐大师，然后从那里开始。

如果历史是线性的，这会很好。（我以前做过。）然而， git rebase -i 所做的是线性化非线性历史。反过来，这会产生许多已经解决的冲突（通常不是我，通常是我在其他机器上，所以我的 rerere 缓存没有多大帮助）。这些冲突存在于我的程序的一部分中，既与我试图确定的错误无关，也与我已确定的次要错误有关。

我对不得不重新解决这些冲突并不感到兴奋。第一次做这项工作很乏味且容易出错！

那么，有没有办法让 git rebase -i 重放历史，包括分支和合并？还有另一个命令可以吗？我是否将这一切都错了，如果是这样，我应该尝试什么？

编辑：根据请求，这是历史的简化版本。 

A-B-C-D-E--F-G-H-I-J-R-S-T
     \              /
      \            /
       α-N-M---P--- 
        \     /
         β   /
          \ /
           γ

在 P 处解决了一些冲突，在 D 处创建了小错误。这段历史被扁平化为： 

A-B'-C'-D'-E'-F'-α'-β'-γ'-N'-M'-P'-F'-G'-H'-I'-J'-Z'

因此在回放历史时，在 N'、M' 和 P' 处存在冲突。

4

1 回答 1

1

要按照您的要求进行操作，我认为您需要分别重新设置每个分支的基础，然后重新进行合并。

在您的示例中（为简洁起见略微截断），您最终会得到以下内容：

           β'-----
          /       \
         α'-N'-...-P'
        /            \
       E'-F'-... -J'-R'-S'-T' [fully-testable-branch]
     /
A-B-C-D-E--F-G-H-I-J-R-S-T [master]
     \              /
      \            /
       α-N-M---P--- 
        \     /
         β ---

（即，您可以在创建分支J，然后变基E..J到C，然后变基α..P到E'，然后合并P'到您的新分支创建R'，然后变基S..T到R'等等等等。

一种更简单的方法可能只是将您的还原存储在D某处（使用存储或仅保存补丁文件），然后将其应用于修复每个二等分的工作副本。

于 2013-04-17T17:18:18.177 回答