以相同方式解决 git rebase 冲突，就像之前一样解决。

Question

我决定回顾性地提交一个历史记录，该记录不在Git中，而是来自另一个旧版本控制系统。因此，我创建了一个孤立分支“newroot”，并将其他版本控制系统中的提交导入其中。参考问题Insert a commit before the root commit in Git? “newroot”分支最终的文件与“master”分支的根提交完全匹配。

现在我想将“master”分支变基到“newroot”孤立分支上，如下所示：

git rebase --onto newroot --root master

问题在于，我需要解决所有合并冲突的提示。这些合并跨越了多年的时间，有数百个。我无法手动解决它们。实际上也没有必要，因为这些合并已经在过去解决过了。由于rebase实际上不会改变内容（因为我正在对相同的树进行rebase），所以我希望Git可以“精确地重放合并”。

有没有一种方法可以指定rebase使用与先前使用的相同的解决方案？

我知道“rerere”可能会有所帮助。但当最初合并时，我必须已经启用了它，对吗？或者我能够回溯地重新创建“rerere”缓存吗？

---

我可以想象一个替代我的任务的解决方案。以某种方式要求Git将“newroot”和“master”分支连接起来，而不实际进行rebase。但我不确定是否可能。

- Martin Prikryl

Answer 1

希望以某种方式要求Git将“newroot”和“master”分支串联起来，而不是进行rebase。但我不确定是否可能。

这被称为嫁接点, 接着使用filter-branch来重写主分支历史记录。
请参见此帖子作为示例或此问题。

在rebase方面，您可以尝试使用类似theirs的合并策略，使用主分支内容解决任何冲突（因为主分支正在进行rebase）。

git rebase --merge -s recursive -X theirs --onto newroot --root master

- VonC

---

谢谢你的回答。嫁接点看起来就是我需要的解决方案。你能否请解释一下为什么需要使用 filter-branch，以及它在嫁接点方面的作用是什么？ - Martin Prikryl

@MartinPrikryl嫁接点是一种纯粹的本地技巧，可以使一个分支被视为另一个分支的父级。您需要使用filter-branch来使此技巧永久化，因为master的每个SHA1都需要反映其新的父级，从第一个SHA1开始（现在将其作为旧导入分支的父级）。再次参见http://bugsquash.blogspot.fr/2010/03/stitching-git-histories.html，其中显示了一个具体示例。 - VonC

好的，所以我添加了嫁接点，然后当我调用filter-branch时，它会看到嫁接点，并根据嫁接点重新创建历史记录。之后，嫁接点就不再需要了。这样正确吗？ - Martin Prikryl

@MartinPrikryl 是的，就像 http://bugsquash.blogspot.fr/2010/03/stitching-git-histories.html 中描述的那样。在 filter-branch 之后将不再需要嫁接点。filter-branch 将更改可以推送的历史记录。嫁接点仅对您的存储库本地有效，永远不会被推送。 - VonC