时间戳

首页 > 解决方案 > Git rebase 从一个父提交到一个新父提交之上（没有旧父提交作为其父提交之一）

git - Git rebase 从一个父提交到一个新父提交之上（没有旧父提交作为其父提交之一）

问题描述

编辑：我们正在使用 Gerrit。本地更改被转移到 Gerrit，在那里进行审查，然后（由 Gerrit）合并到远程 master 分支。

现在我多次遇到一个特定的变基问题，超出了我对 Git 功能的有限理解。想象一下下面的场景（虽然这一切都在发生，但没有其他活动发生origin/master）：

您创建一个A直接基于当前内容的新提交origin/master。在A合并到之前origin/master，您已经创建了一个B直接基于 commit的新提交A。

现在，在提交A审核期间，决定将提交A拆分为两个单独的提交。因此，您创建一个新的提交A0，该提交直接基于origin/master并将部分更改移动A到新创建的A0. 现在A0被合并，成为新的origin/master. 接下来，原来的A（现在更苗条了​​，因为它不再包含移动到的东西A0）基于顶部A0（即顶部origin/master）重新建立，然后合并到origin/master. 到现在为止还挺好。

接下来（准备合并B到origin/master）您尝试B在origin/master. 这就是一切都大错特错的地方（无论如何，对我来说）。

当我运行这些步骤（在 Git bash 中）时，我通常会重新调整更改：

Git 抱怨说有一个必须手动解决的冲突。就我而言，这是一个 changelog.txt 文件。在B的原始历史记录中，此 changelog.txt 文件包含一个合并的更改日志条目，用于以前合并A0和A更改。在新的父B级中，基于此合并的更改日志条目现在已被重新划分为 2 个单独的更改日志条目，显然这不是 Git 可以自动解决的问题。

我很好。解决我自己应该不是特别难，所以我启动了我的图形合并工具。但是，虽然合并工具允许我在一侧的旧组合更改日志条目和另一侧的新单独更改日志条目之间进行选择，但我注意到它B自己提供的新更改日志条目完全丢失（无论哪种选择我做）！！我不明白为什么 Git 会忘记这部分。我究竟做错了什么？

标签： gitgerrit

解决方案

问题是 B 站在原来的 A 之上……你可以这样做：

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

这样，您只移动与 B 相关的唯一修订，而不是来自 A 的任何修订。如果与 B 相关的修订不止一个，只需调整倒数第二个参数的修订数（3 个修订? B~3)。

推荐阅读