通过基于另一个分支创建新的签入来“合并” Git

Question

我有一个git分支dev ，这正是我想要另一个git分支master的位置。 master有一些修补程序，它们在将来都比两者的共同祖先更远，因此此命令链会产生复杂而愚蠢的合并冲突：

git checkout master
git merge dev # Complicated merge conflicts. Boo hiss.

我想做的是在具有dev HEAD状态的master上进行新提交。 从那时起，事情可以以更加理智的方式进行

例：

dev:    A ---> B ---> C ----> D
master: A ---> Y ---> Z ----> *

A是我的共同祖先。 Y和Z是冲突的修补程序更改，因此D，A和Z之间的三向合并是一团糟。

最后我想要这个结果：

• master的HEAD包含与dev上的HEAD完全相同的代码
• 由于两个分支都已推送到远程，因此历史记录不会被重写
• 一个不错的提交消息，解释了这种合并提交

Answer 1

您可以尝试使用ours合并策略：

git checkout dev
git merge -s ours master
git checkout master
git merge dev

与master的合并将创建一个合并提交，但是提交的结果将忽略master所做的所有更改。 然后，您只需简单地将master匹配dev 。

从有关合并策略的文档中 ：

 ours 

这样可以解析任意数量的head，但是合并的结果树始终是当前分支head的树，有效地忽略了所有其他分支的所有更改。 它旨在取代侧支的旧开发历史。 请注意，这与递归合并策略的-Xours选项不同。

Answer 2

要在master上进行新提交，使其完全匹配dev上的内容，可以执行以下操作：

git checkout dev                         # Get the working directory we want.
git symbolic-ref HEAD refs/heads/master  # Move HEAD to master without changing 
                                         # index or working directory.
git commit                               # Create the new commit on master.

这将创建一个与dev分支分开的全新提交。

我的灵感来自这里： https : //stackoverflow.com/a/6070417/2348315

如果遵循此步骤，则开发人员和管理员之间的合并提交将需要解决这些单独的历史记录。 在此操作之后立即创建合并提交应该没有冲突，但是必须是合并提交而不是快速合并。

如果您正在寻找变化，并陷入了您要以描述方式解决的冲突情况，则此方法将很有意义。 如果您的工作流是要合并更改，那么@Cupcake的merge -s ours方法似乎更合适。

Answer 3

1. 将marster分支到新的分支修补程序中
2. 将主重置为您想要的祖先（A）
3. 合并D（== head / dev）到master

有关重置很棒的书gitpro的详细信息： http ://git-scm.com/2011/07/11/reset.html