我从没遇到过太多麻烦，主要是因为在提交代码和作用域时，我倾向于更加谨慎。但是，在与同行合并一些旧项目更改时，我们遇到了一个主要问题，即使用基于基准的方法（由于提交中有大量更改）。因此，这让我开始思考如何解决这种情况下似乎很常见的一些问题。
好吧，请考虑一下我当前正在做一个基准，并且到目前为止我已经应用了一半的提交。我现在正在应用下一个提交并解决一些冲突。我有三个主要问题：
1）如何为这个错误合并的文件重做基础？
2）如果我犯了一个合并/删除或添加文件的错误，如何对正在应用的提交中的所有文件重做基准？
3）如果我发现合并一个或两个已经应用了一些提交的文件时出错，如何在此基础中回退已应用的提交？
PS 。：我知道git reflog和ORIG_HEAD指针。我确实想在保留git rebase操作状态的同时使其工作。我不知道是否有更简单的方法解决这个问题。
答案 0 :(得分：0)
好吧......只是想想.....我想您可能--abort进行了重新设置操作，回到您要更正的重新设置的修订版本，然后再次运行重新设置 < / em>，但指定要应用的新修订版。假设您有一个从master开始的分支A .....它有20个修订版本。所以....您已经在对A〜10进行基础调整了.....，您刚刚注意到它实际上是不正确的... A〜15的基准没有正确地重新设置。所以...这就是我要做的
git rebase --abort # stop rebase
git reflog # find the rebased revision of A~15 on top of master
git checkout rebased-revision-for-A~15
# correct the revision
git add .
git commit --amend --no-edit # correct the rebased revision
# continue with the process
git rebase --onto HEAD A~15 A
这样一来，您就可以像往常一样继续...。只是绕道而行。
答案 1 :(得分：0)
这是（a）一个普遍的难题，（b）具有个人喜好，这使得很难找到一个好的通用解决方案。
解决此问题的方法是记住要重新提交基准副本。我们需要一种在多个提交副本之间建立某种用户友好映射的方法。
也就是说，假设我们有：
O1--O2--O3 <-- branch@{1} (as originally developed with original commits)
/
...--M1--M2--M3--M4 <-- mainline
\ \
\ S1--S2 <-- HEAD (in middle of second rebase)
\
R1--R2--R3 <-- branch (after first rebase)
这里的映射是O1，R1和S1在某种程度上都是“等效的”，即使它们的补丁ID不匹配和/或R1和/或S1中有错误。同样，O2，R2和S2为“等效”，O3和R3为“等效”（没有S3）。
Git不提供返回S1的机制。您可以随心所欲地对S2进行操作，使用git commit --amend来创建其父代为S1的S2a，但是唯一的内置选项是继续运行或完全放弃。如果继续前进，最终名称branch将被剥离R3并粘贴到S3上，并且branch@{1}变为branch@{2}，其中branch@{1}和ORIG_HEAD会记住R3
Git还没有提供将任何O / R / S提交标记为“等效”的可靠机制。您得到的最接近的是git patch-id。当然，如果您在自动变基中使用了压扁或固定操作，那么您真正想要的东西更奇特，例如“ R2等于用Oy压扁的Ox”或其他任何东西。
您可以使用引用日志，或设置分支或标签名称，以便能够恢复提交S2的哈希ID，从中可以找到S1。这使您可以创建自己的类似于rebase的命令，该命令的工作原理是先选择S1，然后停下来进行修改，然后再选择S2，然后再选择R3。但是，您通常只知道如何通过等价映射来做到这一点。
如何从这里进行操作取决于您：您将构建自己的工具。您可以使用git rev-list获取所选提交的哈希ID。只要确保在要挑选的提交序列中有分支合并操作，就可以使用--topo-order获得一致的顺序。