Question

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

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

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

示例：

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

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

最后我想要这个结果：

master的HEAD包含与dev
历史不会被重写，因为两个分支都被推送到遥控器
一个很好的提交消息，解释了这个合并提交

Answer 1

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

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

合并到master将创建合并提交，但提交的结果将忽略master中所做的所有更改。然后，您只需快进master即可匹配dev。

来自documentation for merge strategies：

ours
这解决了任意数量的头，但是合并的结果树始终是当前分支头的树，实际上忽略了来自所有其他分支的所有更改。它旨在用于取代侧枝的旧发展历史。请注意，这与递归合并策略的-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

如果您使用dev和master之间的合并提交，则需要解析这些单独的历史记录。在此操作之后立即创建合并提交应该是无冲突的，但它必须是合并提交而不是快进合并。

如果您正在挑选变化，并且遇到了您想要以您描述的方式解决的冲突情况，那么这种方法是有意义的。如果您的工作流程是合并更改，那么@Cupcake的merge -s ours方法似乎更合适。

Answer 3

将fork marster转换为新的分支修补程序
将master重置为您想要的祖先（A）
将D（== head / dev）合并为主

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

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

3 个答案: