Git 在新的父提交之上从一个父提交变基(没有旧的父提交作为其父提交之一)

Git rebase from one parent commit on top of a new parent commit (that doesn't have the old parent commit as one of its parents)

编辑:我们正在使用 Gerrit。本地更改被转移到 Gerrit,在那里它们接受审查,然后(由 Gerrit)合并到远程主分支。

现在我有很多次 运行 遇到了一个特定的 rebase 问题,这超出了我对 Git 如何运作的有限理解。想象一下下面的场景(虽然这一切都在发生,但 origin/master 上没有其他 activity 发生):

您创建了一个新的提交 A,它直接基于 origin/master 当前的内容。在 A 甚至被合并到 origin/master 之前,您已经创建了一个直接基于提交 A.

的新提交 B

现在,提交 A 正在接受审查,决定将提交 A 拆分为两个单独的提交。因此,您创建了一个直接基于 origin/master 的新提交 A0,并将 A 中的部分更改移动到新创建的 A0 中。现在 A0 被合并,成为新的 origin/master。接下来,原始 A(现在变得更苗条了,因为它不再包含移至 A0 的内容)重新基于 A0(即在 origin/master 之上) ) 然后合并到 origin/master。到目前为止一切顺利。

接下来(准备将 B 合并到 origin/master)您尝试在 origin/master 之上变基 B。这就是一切都出错的地方(无论如何对我来说)。

当我运行步骤(在Gitbash中)我通常会做一个改变:

Git 抱怨有一个冲突必须手动解决。在我的例子中,这是一个 changelog.txt 文件。在 B 的原始历史记录中,此 changelog.txt 文件包含一个合并的更改日志条目,用于之前合并的 A0A 更改。在新的父级 B 中,此组合更改日志条目的基础已被重新拆分为 2 个单独的更改日志条目,显然这不是 Git 可以自动解决的问题。

我没意见。解决我自己应该不是特别困难,所以我启动了我的图形合并工具。但是,虽然合并工具允许我在一侧的旧组合更改日志条目和另一侧的新的单独更改日志条目之间进行选择,但我注意到 B 本身提供的新更改日志条目完全丢失了(无论我做出哪个选择)!我不明白为什么 Git 忘记了这部分。我做错了什么?

问题是 B 站在原来的 A 上面....你可以这样做:

git rebase --onto origin/master B~1 B

这样你只移动与 B 相关的唯一修订,而不是任何来自 A 的修订。如果与 B 相关的修订不止一个,只需调整第二个修订的数量 -最后一个论点(3 次修订?B~3)。