编辑：我们正在使用Gerrit。本地更改被转移到Gerrit，在此处进行审核，然后（由Gerrit合并）到远程主分支。
很多时候，我遇到了一个特定的基准问题，超出了我对Git的功能的有限理解。想象以下情况（发生所有事情时，origin/master上没有其他活动发生）：
您直接基于A上的内容创建一个新的提交origin/master。在A甚至尚未合并到origin/master之前，您已经创建了一个直接基于提交B的新提交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忘记了这部分。我在做什么错了？
答案 0 :(得分：1)
问题是B站在原始A的顶部。...您可以这样做：
git rebase --onto origin/master B~1 B
这样，您将仅移动与B相关的唯一修订，而不会移动任何来自A的修订。如果与B相关的修订不止一个，只需调整倒数第二个自变量的修订数量（3个修订版？B〜3）。