GitHub合并分支“主”
经过多年的svn使用后，尝试了Git和Github。 我似乎有一些基础知识，但有一个项目让我困惑。
-
UserA对FileA进行更改并将其推送到远程服务器（GitHub）
-
UserB对FileB进行更改。 他首先从远程服务器拉出，然后将其更改推送到FileB到远程服务器
-
GitHub提交历史显示来自UserA的推送和来自UserB的推送
-
但是，UserB的提交历史logging中还有一个名为“ https://github.com/xxx/yyy ”的“Merge branch master”的附加条目。 在Github中查看diff会显示这是UserA对FileA所做更改的精确副本
为什么重复显示 – 从UserA推到FileA和合并分支主条目是相同的…第二个似乎是多余的我。
存储在git中的每个版本（“提交”）都是graphics的一部分，根据graphics考虑你在git中做什么通常是有帮助的。
当UserA开始时，假设只创build了两个提交，我们称之为P和Q ：
P--Q (master)
然后，他修改FileA，更改阶段并创build一个代表源代码新状态的提交 – 假设提交被称为R 这有一个单亲，这是提交Q ：
P--Q--R (master)
成功推送后，GitHub存储库的提交图看起来是一样的。
UserB以相同的历史开始：
P--Q (master)
…但创build了一个不同的提交，称为S ，它有他的修改版本的FileB：
P--Q--S (master)
UserB会尝试将其推送到GitHub，但推送被拒绝 – 除非您“强制”推送，否则不允许更新远程分支，除非您推送的版本包含该远程分支中的所有历史logging。 所以，UserB从GitHub中抽取。 拉真的包括两个步骤，提取和合并。 取指更新origin/master ，就像从远程origin远程分支master的状态的caching。 （这是一个“远程跟踪分支”的例子。）
P--Q--S (master) \ R (origin/master)
这个图表中的历史已经发生了变化，所以合并试图通过创build一个兼有S和R作为父母的合并提交（如M ）来统一这两个历史，并希望能够代表两个分支的变化：
P--Q--S--M (master) \ / \ / R (origin/master)
当GitHub显示一个表示提交引入的变化的diff时，在一个父进程提交的情况下很简单 – 它可以从该版本做一个diff。 但是，在提交例如M的情况下，如果有多个父代，则必须select父代以显示差异。 这就解释了为什么为合并提交M显示的差异可能看起来与S或R之一显示的差异相同。 git中的提交由源树的确切状态定义，而不是将树变成该状态的更改。
