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

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

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

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

上图中的字母很重要：即“master”和“final”同时正在开发中，并且必须保留两个分支中的提交。

将“master”合并到“final”然后再合并是否更好（更安全）that回到“大师”？或者从“final”直接合并到“master”会保留之前的提交吗？

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

将“master”合并到“final”，然后将其合并回“master”是否更好（更安全）？或者从“final”直接合并到“master”会保留之前的提交吗？

后者：从“final”直接合并到“master”，保留之前的提交。

git 与 SVN 等其他版本控制系统不同。对于不熟悉的人来说，SVN 将分支视为“存储桶” - 分支/存储桶是固定的（稳定的），并且您必须小心在存储桶之间移动提交。在 SVN 中，在将“最终”分支“重新集成”（伪合并）回“主”之前，您必须将所有最近的“主”提交合并（复制）到“最终”中。 “重新整合”有效地将“final”的尖端复制到“master”的尖端，从而有效地用“final”尖端的精确副本替换“master”。您可能会丢失“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）最终的“装饰”从提交“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

好吧，你能从树上看出哪个分支最初是“主分支”，哪个分支最初是“最终分支”：e-g-i 或 d-f-h？有关系吗？

在 git 中，合并是真正的合并。没有“存储桶”，您不必像 SVN 那样在“存储桶”/分支之间移动提交。只有您正在进化的“树”，树枝（“装饰品”）正在为您在其中的位置添加书签。