-
UserA对FileA进行更改并将其推送到远程服务器（GitHub）
-
UserB对FileB进行了更改。他首先从远程服务器上获取资源，然后将其更改推送到FileB到远程服务器。
GitHub提交历史记录显示来自UserA和从UserB推送 -
然而，在UserB的提交历史记录中还有一个名为'合并分支'主'的 github/xxx/yyy '。在Github中查看diff会显示这是UserA对FileA所做更改的精确副本
为什么会这样重复显示 - 从UserA推送到FileA和合并分支主条目是相同的...第二个对我来说似乎是多余的。
存储在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中抽取。拉真的包括两个步骤，提取和合并。获取更新 origin / master ，它类似于远程分支 master 的远程分支状态的缓存。 code>来源。 （这是一个远程跟踪分支的例子。）
P - Q - S（master） $因此合并试图通过创建合并提交（例如 M ）来统一这两个历史记录，该合并提交同时具有 S 和 R 作为父母，并希望代表两个分支的变化： P - Q - S - M（主） \ / \ / R（原点/主）当GitHub显示一个表示提交引入的变化的差异时，在一个父级提交的情况下它很简单 - 它可以执行差异从那个版本。但是，对于 M 等提交的情况，如果有多个父级，则必须选择一个父级来显示差异。这就解释了为什么为合并提交 M 显示的差异看起来可能与 S 中显示的差异相同。或 R 。 git中的提交由源树的确切状态定义，而不是将树带入该状态的更改。
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.
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 github/xxx/yyy'. Viewing the diff in Github shows this to be an exact replica of the Changes that UserA made to FileA
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.
解决方案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.
When UserA begins, let's say that there had only been two commits created, which we'll call P and 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:
P--Q--R (master)After successfully pushing, the commit graph for the GitHub repository looks the same.
UserB started with the same history:
P--Q (master)... but created a different commit, say called S, which has his modified version of 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 master from the remote origin. (This is an example of a "remote-tracking branch".)
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 S and R as parents, and hopefully represents the changes from both branches:
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 M might appear to be the same as that shown for one of S or 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合并分支'主'
发布评论