我有一个看起来像这样的历史
H o updated ctools, ds
G M─┐ merged module file
F │ o find page
E o │ work on download restriction
D o─┘ Report downloading/emailing WIP
C o migration: find and replace URLs throughout notes
B o various local things
A o initial commit
进一步落后，A来自远程主人。现在遥控器已经移动了，我想使用git rebase来更新我的历史记录，以便在最新的远程更改之上。
所有这些提交都是在不在远程主控的代码中，但是git rebase会让我失望，因为它似乎无法理解如何处理 D：G ：在 G 合并的侧分支。 Git rebase尝试按顺序应用它们，没有合并，即A B C D E F H...但 F 不适用于 E 。我计划需要多次重新设置才能使我的代码保持在最新源代码的开发之上，所以我想要一个持久的解决方案。
如何判断git是否可以在 G 找到冲突的答案？或者我怎样才能做其他事情，以便git rebase能够回复提交？我很乐意将 D：G 压缩成 D'，如果这样可以让事情变得更容易。
答案 0 :(得分：2)
Git与master合并是您方案中的最佳选择，因为rebase不是为合并提交而设计的（G是您的问题）。但是如果你真的想和git rebase -p没有产生预期的结果，你可以：
此处首选合并的其他原因：
那些你试图改变的提交可能已经属于遥控器上的某个功能分支，将其中的很多功能分支到另一个远程分支只会导致大量的重复提交，这可能会让其他人感到困惑
如果这些提交仅在您的本地分支中，通过变基（但不一定是推送）它们，您实际上是“扣留”它们直到它们最终被推送或合并为止。这可能会对其他人造成破坏性，因为它看起来像是在很短的时间内突然出现的大量提交;合并应该是工作流程中的常规活动。
也就是说，如果您计划以任何理由（例如使用git-svn）定期进行rebase，最好的方法是为您希望重新定义和/或限制它们的提交保留线性历史记录。少数。对于涉及合并的一系列提交，这些合并需要从前到后折叠（如迷你版）。