3

我有一段看起来像这样的历史

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。我计划需要多次 rebase 以使我的代码保持在最新起源的开发之上，所以我想要一个持久的解决方案。

我如何告诉 git 可以在G找到冲突的答案？或者我该怎么做才能让 git rebase 能够回复提交？如果这让事情变得更容易，我很乐意将D:G 压缩到D'中。

4

1 回答 1

2

Git 与 master 合并是您方案中的最佳选择，因为 rebase 不是为合并提交而设计的（G 是您的问题）。但是，如果您真的想要并且git rebase -p没有产生预期的结果，您可以：

  1. rebase AE（然后是 A'-E'）
  2. 在 D' 上单独重新应用 F（通过cherrypick 或其他方式）成为 F'
  3. 合并 E' 和 F' 成为 G'
  4. Cherrypick H 在 G' 的顶部

此处首选合并的其他原因：

  1. 您尝试变基的那些提交可能已经属于远程上的某个功能分支，将其中的很多变基到另一个远程分支只会导致大量重复提交，这可能会让其他人感到困惑。

  2. 如果这些提交仅在您的本地分支中，则通过重新定位（但不一定是推送）它们，您实际上是在“保留”它们，直到它们最终被推送或合并。这可能会对其他人造成干扰，因为它看起来像是在短时间内突然出现了大量的提交；合并应该是工作流中的常规活动。

也就是说，如果您出于任何原因（例如使用 git-svn）计划进行定期变基（例如使用 git-svn），最好的方法是为您希望变基的提交维护线性历史记录和/或将它们限制为少量. 对于涉及合并的一系列提交，这些合并需要从前向后折叠（如迷你变基）。

于 2012-11-23T14:46:09.310 回答