理解带有意外提交和未完成提交的分支上的rebase的git问题

我们有一些问题与一个分支机构在过去不知何故搞砸了。。。以下情况：

• D是一个交付分支，我们从供应商处接收更改
• M是主分支
• F是一个特征分支
• 来自D的提交合并到M
• F用M重设基址
• M包含F（F2）的意外提交，M3是该提交的还原

有没有解释为什么将F1-F2-F3重新固定到F2-M3上会使F2松动

似乎有效的方法是将F中的所有更改压缩为一个提交，然后进行重新基址，在这种情况下，F2中引入的更改仍然存在

我试图用rebase交互模式重写M的历史，并保留合并。。。我的想法是删除意外提交（F2）和它的恢复（M3），但结果没有给我任何信心，我没有失去任何东西

我还遇到了以下问题（在这里的bug中提到：），这使我放弃了重写大师历史的想法

由--preserve merges--interactive提供的待办事项列表不存在 表示修订图的拓扑。编辑提交和 重写其提交消息应该可以正常工作，但尝试 重新排序提交往往会产生违反直觉的结果

---

我猜

F

上的

F2

是

F

上的

F2

的一个精选，而不是如图所示的合并

在重定基址时，git将挑选

F

中但不在

M

中的所有提交，因为

F2

在两个分支中，它不会挑选它

如果您想保留它，一个解决方案是使用

git-rebase

的所有参数：

git rebase --onto M $(git merge-base F M) F
# equivalent to:
# git rebase --onto M D1 F

这将重新确定

F

中所有提交的基础，但不会在

M

和

F

（

D1

）==>

F1-F2-F3

的共同祖先中，在

M

的末尾

---

另一种解决方案是执行交互式重基（

git-rebase--interactive mf

），然后在重基todo中显式添加

pick F2

：

pick F1
pick F2
pick F3

---

图表只是一个情况的例子，不确定变化是如何发生的。但是你的解释是可以理解的，谢谢！我的同事正在研究这个分支，在壁球解决方案之后，他已经离开了。。。下次遇到这种情况时，我们将尝试您建议的重新设置基础。

git pull --rebase origin master

git rebase --onto M $(git merge-base F M) F
# equivalent to:
# git rebase --onto M D1 F

pick F1
pick F2
pick F3