我从来没有遇到太多关于rebase的麻烦，主要是因为我在提交代码量和范围时往往更加小心。但是在努力将一些遗留项目更改与我的同行合并时，我们使用rebase-first方法遇到了一个主要问题（因为提交中有大量的更改）。所以这让我思考如何解决这些在这种情况下看起来很常见的问题。
好了，请考虑我目前正在做一个rebase，到目前为止我已经应用了一半的提交。我现在正在应用下一次提交并解决一些冲突。我有三个主要问题：
1）如何为这个错误合并的文件重做rebase？
2）如果我做了更多合并/删除或添加文件的错误，我如何为我正在申请的提交中的所有文件重做rebase？
3）如果我发现错误合并了一两个已经应用了一些提交的文件，我怎么回去已经应用了这个rebase中的提交？
PS。：我知道git reflog和ORIG_HEAD指针。我确实希望在保留git rebase操作状态的同时使其工作。我不知道是否有更简单的方法。
好吧....只是想......我想你可能会对rebase操作进行--abort，回到你想要纠正的重新修订版本，然后再次运行rebase，但指定要应用的新修订段。假设你有一个从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
这样你就可以像往常一样继续......只有绕道而行。
这是（a）一般来说是一个难题，并且（b）通过个人偏好来实现，这使得很难有一个良好的通用解决方案。
考虑解决问题的方法是记住rebase复制提交。我们需要一种方法来在多个提交副本之间建立某种用户友好的映射。
也就是说，假设我们有：
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压扁的牛”等等。
您可以使用reflog，或设置分支或标记名称，以便能够恢复提交S1的哈希ID，您可以从中找到S1。这允许你制作自己的类似rebase的命令，通过樱桃选择S1并停止修改，然后挑选S2并继续挑选R3。但是你通常只用等价映射知道如何做到这一点。
如何从这里开始取决于你：你将构建自己的工具。您可以使用git rev-list获取所选提交的哈希ID。只要确保如果在提交序列中存在分支和合并操作，那么您已经使用--topo-order来获得一致的排序。