GitHub合并分支'主'

Question

在使用 svn 多年后，一直在尝试 Git 和 Github。我似乎已经掌握了基础知识，但有一项让我感到困惑。

• UserA 对 FileA 进行更改并推送到远程服务器 (GitHub)

• UserB 对 FileB 进行了更改。他首先从远程拉 服务器，然后将他对 FileB 的更改推送到远程服务器

• GitHub 提交历史显示来自 UserA 的推送和来自 UserB 的推送

• 但是，来自 UserB 的提交历史记录中还有一个名为“https://github.com/xxx/yyy 的合并分支 'master'”的附加条目。在 Github 中查看差异表明这是 UserA 对 FileA 所做更改的精确副本

为什么显示这个重复项 - 从 UserA 到 FileA 的推送和 Merge 分支主条目都是相同的……第二个对我来说似乎是多余的。

Answer 1

存储在 git 中的每个版本（“提交”）都构成了图表的一部分，根据该图表来思考您在 git 中所做的工作通常很有帮助。

当 UserA 开始时，假设只创建了两个提交，我们将其称为 P 和 Q：

P--Q (master)

然后，他修改 FileA，阶段更改并创建一个代表源代码新状态的提交 - 假设提交名为 R。这有一个单亲，即提交Q：

P--Q--R (master)

成功推送后，GitHub 存储库的提交图看起来相同。

UserB 以相同的历史开始：

P--Q (master)

...但创建了一个不同的提交，例如称为 S，其中包含他修改后的 FileB 版本：

P--Q--S (master)

UserB 尝试将其推送到 GitHub，但推送被拒绝 - 除非您“强制”推送，否则不允许更新远程分支，除非您推送的版本包含该远程中的所有历史记录分支。因此，UserB 从 GitHub 中提取。拉动实际上包括两个步骤，获取和合并。 fetch 更新origin/master，这就像来自远程origin 的远程分支master 的状态缓存。 （这是一个“远程跟踪分支”的例子。）

P--Q--S (master)
    \
      R (origin/master)

此图中的历史已经分歧，因此合并尝试通过创建合并提交（例如 M）来统一这两个历史，该合并提交同时具有 S 和 R 作为父级，并希望代表从两个分支：

P--Q--S--M (master)
    \   /
     \ /
      R (origin/master)

当 GitHub 向您显示代表由提交引入的更改的 diff 时，对于具有一个父级的提交来说，这很简单 - 它可以只从该版本进行 diff。但是，对于像M 这样的提交，如果有多个父级，它必须选择一个父级来显示差异。这就解释了为什么合并提交M 显示的差异可能与S 或R 之一显示的差异相同。 git 中的提交由源树的确切状态定义，而不是使树进入该状态的更改。