Git 中的合并是对称的吗? [英] Are merges in Git symmetric?

问题描述

假设我们有两个分支(B 和 C)，它们与一个共同的祖先 A 不同.从 B 合并到 C 会产生与从 C 合并到 B 的结果相同的结果吗?

Lets say we have two branches (B and C) that have diverged from a common ancestor A. Will merging from B to C produce the same result as merging from C to B?

  A
  |
 / 
B   C

澄清 - 我假设任何手动合并冲突解决方案都会在两个方向发生.但是发生的任何自动合并会导致选择相同的代码吗?这是我的假设，因为提交日期在两个方向上都是相同的.

To clarify- I'm assuming that any manual merge conflict resolutions will occur in both directions. But will any automatic merges that occur result in the same code being chosen? This is what I'm assuming, since the commit dates are identical in both directions.

进一步澄清 - 我知道实际合并会根据方向产生彼此的镜像".我只是询问自动解决的冲突.

To further clarify - I know that the actual merging results in "mirror images" of each other based on the direction. I'm just asking about the automatically resolved conflicts.

推荐答案

对于默认合并，答案是肯定的.三向合并找到一个共同的祖先，然后应用双方的差异，这是一个不依赖于顺序的操作.合并排序和交换性的话题在 git list (如果你喜欢那种东西，那就是).注意 B into C 和 C into B 应该是对称的，但是对于 (B into C) into A 和 B into (C into A).

The answer is yes for default merges. A three-way merge finds a common ancestor and then applies the differences from both sides, an operation that isn't order dependent. The topic of merge-ordering and commutativity generated a fascinating discussion on the git list (if you're into that kind of thing, that is). Note B into C and C into B should be symmetric, but the same cannot necessarily be said for (B into C) into A versus B into (C into A).

再详细说明一下，根据下面 Vince 的评论和 seh 对问题的评论，B into C 和 C into B 之间会有两个明显的区别，两者都不会影响问题中引用的自动合并解决方案.

To elaborate a bit more, based on Vince's comment below and seh's comment on the question, there will be two noticeable differences between B into C and C into B, neither of which affect the automatic merge resolution referenced in the question.

首先，历史会有所不同.合并提交的父项将根据合并顺序发生变化.对于这些示例，我将使用first_branch"和second_branch"，因此我可以保留字母来表示提交.

First, history will be different. The merge commit's parents will change depending on the merge order. For these examples, I'm going to use "first_branch" and "second_branch", so I can reserve letters to represent commits.

git checkout first_branch && git merge second_branch

E <- merge commit
|
| D <- second_branch's tip
| |
| C <- another commit on second_branch 
| |
| B <- and another
|/
A <- first_branch's tip before the merge

在这种情况下，E 的第一个父级"，E^1，是合并前 first_branch 的提示.second_branch 是合并提交的第二个父级"，又名 E^2.现在考虑相反的情况:

In this case, the "first parent" of E, E^1, is first_branch's tip before the merge. second_branch is the "second parent" of the merge commit, aka E^2. Now consider the reverse:

git checkout second_branch && git merge first_branch

E <- merge commit
|
| D <- first_branch's tip
| |
| C <- another commit on first_branch 
| |
| B <- and another
|/
A <- second_branch's tip before the merge

父母是颠倒的.E^1 是合并前的 second_branch 的尖端.E^2 是 first_branch 的尖端.

The parents are reversed. E^1 is the tip of second_branch before the merge. E^2 is the tip of first_branch.

其次，冲突的显示顺序会颠倒.在第一种情况下，冲突可能如下所示:

Second, the display order of conflicts will reverse. In the first case, a conflict might look like this:

<<<<<<< HEAD
This line was added from the first_branch branch.
=======
This line was added from the second_branch branch.
>>>>>>> second_branch

在第二种情况下，同样的冲突看起来像这样:

In the second case, the same conflict would look like this:

<<<<<<< HEAD
This line was added from the second_branch branch.
=======
This line was added from the first_branch branch.
>>>>>>> first_branch

这些差异都不会影响自动合并分辨率，但是当您反转三向合并顺序时它们会出现.

Neither of these differences affect automatic merge resolution, but they do appear when you reverse three-way merge order.

这篇关于Git 中的合并是对称的吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！