git GitHub 合并分支“主”

GitHub Merge branch 'master'

提问by JonoB

Been trying out Git and Github after many years of svn use. I seem to have the basics down, but one item is confusing me.

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

• UserA makes a change to FileA and pushes to the remote server (GitHub)

• UserB makes a change to FileB. He first pulls from remote server, and then pushes his change to FileB to the remote server

• GitHub commit history shows the push from UserA and the push from UserB

• However, there is an additional entry in the commit history from UserB called 'Merge branch 'master' of https://github.com/xxx/yyy'. Viewing the diff in Github shows this to be an exact replica of the Changes that UserA made to FileA

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

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

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

• 但是，UserB 的提交历史记录中有一个额外的条目，称为https://github.com/xxx/yyy的“合并分支‘master’ ”。查看 Github 中的差异显示这是用户 A 对文件 A 所做更改的精确副本

Why is this duplicate shown - both the push from UserA to FileA and the Merge branch master entries are identical...the second seems superfluous to me.

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

回答by Mark Longair

Each version ("commit") stored in git forms part of a graph, and it's frequently helpful to think about what you're doing in git in terms of that graph.

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

When UserA begins, let's say that there had only been two commits created, which we'll call Pand Q:

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

P--Q (master)

He then modifies FileA, stages that change and creates a commit that represents the new state of the source code - let's say that commit is called R. This has a single parent, which is the commit Q:

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

P--Q--R (master)

After successfully pushing, the commit graph for the GitHub repository looks the same.

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

UserB started with the same history:

UserB 以相同的历史记录开始：

P--Q (master)

... but created a different commit, say called S, which has his modified version of FileB:

...但创建了一个不同的提交，比如 called S，它有他修改过的 FileB 版本：

P--Q--S (master)

UserB tries to push that to GitHub, but the push is refused - unless you "force" the push, you're not allowed to update a remote branch unless the version you're pushing includes all of the history in that remote branch. So, UserB pulls from GitHub. A pull really consists of two steps, fetching and merging. The fetch updates origin/master, which is like a cache of the state of the remote branch masterfrom the remote origin. (This is an example of a "remote-tracking branch".)

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

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

The history in this graph has diverged, so the merge tries to unify those two histories by creating a merge commit (say M) which has both Sand Ras parents, and hopefully represents the changes from both branches:

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

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

When GitHub shows you a diff that represents the changes introduced by the commit, it's simple in the case of a commit with one parent - it can just do a diff from that version. However, in the case of a commit such as M, with more than one parent, it has to choose a parent to show the diff against. That explains why the diff shown for the merge commit Mmight appear to be the same as that shown for one of Sor R. Commits in git are defined by the exact state of the source tree, not the changes that got the tree into that state.

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