如何让我的提交历史与git rebase兼容？

Question

我有这样的历史记录

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'。

- artfulrobot

Answer 1

在您的情况下，Git与主分支合并是最好的选择，因为rebase不适用于合并提交（G是您的问题）。但如果您真的想要并且“git rebase -p”没有产生预期结果，您可以：

1.重新定位A-E（然后是A'-E'） 2.单独重新应用F（通过cherrypick或其他方式）在D'之上成为F' 3.合并E'和F'以成为G' 4.在G'之上使用cherrypick H

其他优先使用合并的原因：

1.您正在尝试重新定位的那些提交可能已经属于远程的某个功能分支，在另一个远程分支上重新定位许多提交将导致大量重复提交，这可能会使其他人感到困惑。 2.如果这些提交仅存在于您的本地分支中，通过重新定位（但不一定推送）它们，您实际上正在“保留”它们，直到它们最终被推送或合并。这可能会对其他人造成干扰，因为它看起来像在短时间内突然出现了大量提交；合并应该是工作流程中的常规活动。

话虽如此，如果您计划出于任何原因进行定期重新定位（例如使用git-svn工作），则最好的方法是维护您希望重新定位和/或将它们限制在少量的提交中的线性历史记录。对于涉及合并的一系列提交，这些合并需要从前向后折叠（就像小型重新定位）。

- prusswan

---

谢谢你的帮助。正如我所说，我需要经常重复这个过程，所以我真的很喜欢你提出的1-5作为一次性解决方案的想法。你能否在（1）中给出更多关于如何进行部分变基的指针？此外，如果我可以这样做，那么重新定位A-D不是更容易，然后获取补丁D：G，将其应用为E'，然后再次在其余部分上使用重新定位（H继续下去，在树的其余部分中也有其他分支合并的示例）。 - artfulrobot

@artfulrobot，您可以压缩一些提交，但这必须由您自行决定，因为原始提交的意图并不总是被保留。如果H继续下去，强烈建议进行合并。 - prusswan

一些背景：源代码是Drupal。我的大部分代码都在一个新模块中，专门针对我的使用情况，永远不会成为源代码的一部分。有时我会修补核心Drupal。当Drupal发布安全更新时，我希望我的代码能够在其之上应用。任何我核心的补丁都需要重新审查，因为它们可能不再必要/正确。我与我的各种Drupal项目共享这些补丁，这就是为什么rebase很好。合并会使这个过程更加混乱，我会失去我的补丁。 - artfulrobot

@artfulrobot，如果是这样的话，我建议您将核心补丁保留在单独的分支中，并以便于变基的方式进行维护。 - prusswan