我们有一个分支的问题，过去不知何故搞砸了......以下情况：
- D 是一个交付分支，我们从提供商那里接收更改
- M 是主分支
- F 是功能分支
- 来自 D 的提交合并到 M
- F 与 M 重定基数
- M 包含 F (F2( 的意外提交，M3 是该提交的还原
D D1-D2-D3-O \ \___________ \ \ M \-M1-M2-D2-F2-M3-D3-O \ / \/F \-F1-F2-F3-o
现在我们再次尝试用 M 重定 F 的基数，但我们用 M3 恢复的更改 F2 最终丢失了。
D D1-D2-D3-O \ \___________ \ \ M \-M1-M2-D2-F2-M3-D3-O \ \ F \-F1-F3-o
在分支 F 中，我们只需使用：
git pull --rebase origin master
有没有解释为什么将 F1-F2-F3 重定基数到 F2-M3 会失去 F2？
似乎有效的方法是将 F 中的所有更改压缩为单个提交并进行变基，在这种情况下，F2 中引入的更改仍然存在。
我试图使用变基交互模式重写 M 的历史并保留合并......我的想法是删除意外提交(F2(和恢复(M3(，但结果并没有给我任何信心，我没有丢失任何东西。
我还遇到了以下内容(在错误下提到：https://git-scm.com/docs/git-rebase(，这使我放弃了重写大师历史的想法。
由 --preserve-merges --interactive 呈现的待办事项列表没有 表示修订图的拓扑。编辑提交和 改写他们的提交消息应该可以正常工作，但尝试 重新排序提交往往会产生违反直觉的结果。
我猜M上的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末尾重定M和F的共同祖先(D1(==>F1-F2-F3
另一种解决方案是执行交互式变基(git rebase --interactive M F(，然后在变基待办事项中显式添加pick F2：
pick F1
pick F2
pick F3