Git合并如何处理同时提交？

给定一个具有两个分支的仓库，每个分支具有独立的提交：

Branch  Commits
------  -----------

final:        e-g-i
             /     \
master: a-b-c-d-f-h-?

上表中的字母是有意义的：即“ master”和“ final”正在同时开发中，并且必须保留两个分支中的提交。

它是更好（更安全）合并的“主人”到“最后”，然后合并这回“主人”？还是将直接从“最终”合并到“主”中的提交保留在那里？

我知道合并冲突可能会出现。我更担心的是，在将“ final”合并到“ master”之后，我们不会丢失任何提交给“ master”的代码。

1> Bert F..：

---

将“ master”合并到“ final”，然后再将其合并回“ master”，是否更好（更安全）？还是将直接从“最终”合并到“主”中的提交保留在那里？

后者：从“最终”保留的提交直接合并到“主”中。

git与其他版本控制系统（如SVN）不同。对于不熟悉的用户，SVN会将分支视为“存储桶”-分支/存储桶是固定的（稳定的），并且您必须小心在存储桶之间移动提交。在SVN中，您必须先将所有最近的“主”提交合并（复制）到“最终”，然后再将“最终”分支“重新集成”（伪合并）回“主”。“重新整合”有效地将“最终”的笔尖复制到“母版”的笔尖上，从而有效地将“母版”的笔尖替换为“最终”的笔尖的精确副本。您可能会丢失“ master”中所有没有被合并（复制）到“ final”中的提交。

就像我说的，git是不同的。在git中，我喜欢将存储库树（提交）视为稳定的，而是将其移动的“分支”-将分支视为挂在提交之外的小标签/装饰。

我将以不同的方式绘制您的树-实际上，我将在创建提交“ i”之前绘制它：

              final
                |
            e - g
          /
a - b - c 
          \
            d - f - h
                    |
                  master

现在让我们提交“ i”：

                  final
                    |
            e - g - i
          /
a - b - c 
          \
            d - f - h
                    |
                  master

只有两件事发生了变化。（1）现在忽略分支“ decorations”，我们看到新的提交“ i”是从其父提交“ g”创建的，（2）最后的“ decoration”从提交“ g”移至“ i”。

让我们将final合并到master中-也就是说，让我们更新master以使其包含来自final的更改：

                  final
                    |
            e - g - i
          /           \
a - b - c              j
          \           /|
            d - f - h  |
                       |
                     master

现在，“主”分支装饰已移动。“最终”分支机构的装饰保持不变。“ j”提交是由2个父级创建的合并提交：“ h”和“ i”。

但是，如果我们将master合并到final中，即更新了final，以便包含master的更改，该怎么办：

                     final
                       |
            e - g - i  |
          /           \|
a - b - c              j
          \           /
            d - f - h
                    |
                  master

现在，“最终”移动了，“大师”留在了原地。请注意，合并是真正的合并-来自两个分支的更改都在提交'j'中。不管哪个分支合并到哪个分支，“ j”都是相同的-唯一的区别是哪个分支“装饰”被移动了。（并且这些分支“装饰”很容易移动。）

为了完整起见，让我们将另一个分支合并回第一个分支（谁先合并到谁无关紧要，只要这次我们在另一个方向合并即可）。注意只有修饰动作-不需要新的提交（在git行话中，它是“快进的”），因为'j'已经包含了两个分支的两组更改：

                     final
                       |
            e - g - i  |
          /           \|
a - b - c              j
          \           /|
            d - f - h  |
                       |
                     master

实际上，几天后，让我们看一下树（我删除了“最终”分支-完成了）：

            e - g - i
          /           \
a - b - c              j - k - l - m
          \           /            |
            d - f - h              |
                                   |
                                 master

好的，您可以从树中分辨出哪个分支最初是“主”对哪个分支是“最终”：egi或dfh吗？有关系吗？

在git中，merge是真正的合并。没有“存储桶”，也不必像在SVN中一样在“存储桶” /分支之间移动提交。您仅在进化“树”，而分支（“装饰”）则将您在其中的位置加为书签。

---

对于它的价值，您可以*知道哪个分支最初是“主”（好吧，因为），因为合并提交“ j”的第一个父级是运行“ git merge”时的当前分支。因此，在这种情况下，例如，如果“ j ^”是“ h”，而“ j ^ 2”是“ i”，则表明提交“ j”是通过将“ i”合并到“ h”中创建的。（这是`git rev-list`中的--first-parent`的目的。）尽管在这里并没有什么大的不同，所以这只是一个旁注。