合并后分支比原点领先多个提交

其他 6 个提交用于分支 x

啊哈，那正是你错的地方。请记住，Git 中的分支不是提交链，正如您所想的那样。这是一次提交。通过沿着父链向后走，其他一切都只是可以从一次提交中到达的提交。

嗯，一个合并提交，比如你刚刚创建的，有两个父级，其中一个是刚刚合并的分支提交。所以合并后，以前只能x从master（）访问的所有提交现在也可以从（因为x现在是 的父级之一master，这是合并提交）。

因此，Git 在这里所做的就是计算现在可以访问的提交数量，从master无法访问的提交数量origin/master，如下所示：

[origin/master] 7
X--X------------------X [master]
.../ /
/
----X--X--X--X--X--X [origin/x, x]
1 2 3 4 5 6


Git 不关心导致这种情况的拓扑结构；它只是报告一个数字。

所以 Git 报告的数字可能看起来不直观，但实际上它是完全准确的。这是一个有用的数字！Git 正确地报告说，如果您现在要推送，导致origin/master向上移动到master，origin/master然后将能够达到它目前无法达到的 7 个提交，并且远程存储库将获得它当前没有的 7 个提交。

• 
  I didn&＃039;t say Git&＃039;s messages were phrased particularly beautifully. On the contrary, a lot of the names and terms that Git uses in talking to you are misleading. I&＃039;ve never liked "ahead" and "behind". (In fact I don&＃039;t like _anything_ about the way `git status` talks.) Still, I&＃039;ve tried to show you that "ahead" does make a certain sense: `master` does indeed reach 7 commits that `origin/master` doesn&＃039;t yet know about, so in terms of progress (or size?), `master` is 7 commits "ahead".