Git merge diff3风格需要解释_Git_Merge_Branching And Merging

Git merge diff3风格需要解释

git merge

Git merge diff3风格需要解释,git,merge,branching-and-merging,Git,Merge,Branching And Merging,我已经合并了两个分支，并且出现了冲突，我需要一些提示，从哪里开始，从哪里结束，等等。我已经用一些伪造的数据替换了代码，以便更容易阅读和讨论 <<<<<<< HEAD aaaaaa ||||||| merged common ancestors <<<<<<< Temporary merge branch 1 bbbbbb ======= cccccc >>>>>

我已经合并了两个分支，并且出现了冲突，我需要一些提示，从哪里开始，从哪里结束，等等。我已经用一些伪造的数据替换了代码，以便更容易阅读和讨论

<<<<<<< HEAD
    aaaaaa
||||||| merged common ancestors
<<<<<<< Temporary merge branch 1
    bbbbbb
=======
    cccccc
>>>>>>> mybranch
    dddddd
<<<<<<< HEAD
    eeeeee
||||||| merged common ancestors
    ffffff
||||||| merged common ancestors
    gggggg
=======
>>>>>>> Temporary merge branch 2
=======
    hhhhhh
>>>>>>> mybranch

>>mybranch

这里有一篇关于。它指出，很难判断在这种样式中是否添加或删除行

如果你在寻找具体信息，我建议你改进你的问题。很难说你在问什么。

你在这个例子中看到的（使用

临时合并分支

标记）是diff3与交叉合并冲突的结果。我将用一系列的定义来解释这一点

定义

合并基：两个合并分支最近偏离的提交。发生合并冲突时，对两个分支中的相同行进行了不同的更改。合并基包含分支更改这些行之前的行
合并的共同祖先：diff3输出一个额外的“中间”部分，显示合并基础中的行。这是两个分支的起点
交叉合并：两个分支以一种不可能是快速合并的方式相互合并的合并历史。下面我举一个例子。在交叉合并的情况下，有多个合并基础
临时合并分支：当存在多个合并基时，diff3尝试将它们合并在一起（使用临时合并分支），以形成一个共同的祖先，显示在diff3的中间部分。当不存在冲突时，这可以无缝地工作，但当存在冲突时，您会在中间合并的公共祖先部分中看到临时合并分支的冲突标记

交叉合并冲突场景示例每当两个分支在不同的时间点相互合并时，就会发生交叉合并

m3 *
   |\
   | \
   |  * B1
   |  |
m2 *  * B0
   |\/|
   |/\|
m1 *  * A
   | /
   |/
m0 *

考虑以下事件序列：

```
m0
```
作为原点存在/master
我创建了一个功能分支
```
feature-a
```
，其中一个提交
```
a
```
```
m1
```
被其他人提交给master
我启动了一个新的功能分支
```
feature-B
```
，它建立在
```
a
```
我将
```
origin/master
```
（
```
m1
```
）合并到
```
feature-B
```
。这是冲突，我解决了。合并提交是
```
B0
```
我实现了feature-B，并将工作提交为
```
B1
```
```
feature-A
```
已准备就绪，因此有人将其合并到
```
master
```
中。这是矛盾的。它们解析了它，但它们的解析与
```
B0
```
中的解析不同。合并提交是
```
m2
```
```
feature-B
```
已准备就绪，因此有人将其合并到
```
master
```
中。git试图确定合并基数，但是
```
m1
```
和
```
A
```
都可以作为合并基数。git将
```
m1
```
和
```
A
```
合并到临时合并分支中，这会导致冲突。我们在合并的公共祖先部分看到diff3输出，类似于OP的问题

读取输出禁用diff3后，此合并冲突将如下所示：

<<<<<<< HEAD
    aaaaaa
=======
    hhhhhh
>>>>>>> mybranch

与冲突解决方案保持一致。在本例中，临时合并基础冲突的发生只是因为

m2

和

B0

具有不同的冲突解决方案。如果他们以相同的方式解决了冲突，

m3

将是一个干净的合并。但要意识到，这是一个简单的纵横交错的合并，应该有相同的解决方案。其他情况可能有不同的解决方案。当合并点之间有两个以上的合并基和多个提交时，事情会变得更加复杂。这就是说，如果你在纵横交错的情况下故意与冲突解决方案不一致，那么以后可能会头疼

这种差别很奇怪。你能给我们看看原来的分支机构吗？原始文件是否包含合并标记

Um，您添加了两次相同的答案？：。在第3步和第4步之间，修复此问题的方法是重新设置主文件的基础吗？一般来说，我讨厌合并提交，所以我不会有b0，但我对这种“交叉合并”是新手，所以我试图看看，如果没有合并提交，这种交叉合并是否可行。如果您和您的队友重新设置基础，使您的历史是线性的，那么如果您的历史在您的场景中是线性的，则不可能有多个合并基础，因此不可能有交叉合并。非常好的链接，谢谢。我对这篇文章的理解不同：在默认冲突样式（未显示）中很难区分添加/删除，但diff3包含了| ||||标记以提供上下文，允许我们推断更改是添加还是删除。
m3 *              m3 *
   |\                |\
   | \               | \
   |  * B1           |  * B1
   |  |              |  |
m2 *  * B0   VS   m2 *  |
   |\/|              |\ |
   |/\|              | \|
m1 *  * A         m1 *  * A
   | /               | /
   |/                |/
m0 *              m0 *