Note: this particular question is, at the time I write this answer, quite old. It was posted three years before the first release of a version of Git that fixed many of these problems. It seems worth adding a modern answer along with explainers, though. The existing accepted answer suggests running git fetch -p,1 which is a good idea, although less-often required these days. It was much more necessary before Git version 1.8.2 came out; that Git was released three years after the original question.
1 -p或——prune选项不是必需的，只建议在链接的答案中作为括号。请参阅下面较长的部分了解它的功能。
这到底是怎么发生的呢?
原来的问题是这样的:
这到底是怎么发生的呢?
这里的问题是，在git推送origin master之后，OP运行git状态，并看到消息On branch master后面跟着Your branch领先'origin/master' 1 commit。要正确地回答这个问题，我们需要把它分解成几个部分。
首先，每个(本地)分支都有一个上游设置
这种说法实际上有点太强烈了。在您自己的Git存储库中，您自己的每个本地分支都可以有一个设置，Git称之为上游。或者，这个分支没有上游。旧版本的Git在将此称为上游设置方面不太一致，但在现代Git中，它更加一致。我们还有git分支——set-upstream-to和git分支——unset-upstream用于设置或清除上游。
这些——set-upstream-to和——unset-upstream会影响当前分支。当前分支是你所在的那个，当git状态显示在分支xyzzy上时。你可以使用git checkout或git switch.2来选择这个分支不管你查过哪个分支，这就是你要查的
如果你使用——unset-upstream，这将移除当前分支的上游。没有了上游，这就停止了关于领先、落后或偏离的信息。但是这条消息是有用的，所以您可能不应该仅仅删除上游来阻止它发生。(如果你觉得它没什么用的话，可以随意忽略这条消息——毕竟这不是一个错误。)
If you run git branch --set-upstream-to=origin/xyzzy, that sets the current branch's upstream to origin/xyzzy. For a branch named xyzzy, this would be the typical correct setting. Some acts of creating branches automatically set the (typically-correct) upstream, and some don't, so if you used a branch-creating operation that set the right upstream automatically, you need not do anything. If you want a different upstream, or if you used a branch-creating operation that set no upstream, you can use this to change the upstream.
你可以设置upstream为:
另一个你自己的(本地)分支:git branch——set-upstream-to=experiment使你自己的本地实验成为当前分支的上游;或
任何远程跟踪名称，例如origin/main或origin/master或origin/xyzzy。这些是git分支-r输出的名称。Git将这些远程跟踪分支命名为(我喜欢在这里省略“分支”这个词)，我们将在稍后详细讨论它们。
git status打印的前进、落后、最新或发散的消息来自于运行看起来有点神奇的命令:
git rev-list --count --left-right $branch...$upstream
其中$branch是当前分支的名称，$upstream是其上游设置的字符串(from git branch——set-upstream-to - above)。在这两个名字之间有三个点，count, left-right，三个点都需要get git rev-list来吐出这两个数字。
2If you have Git 2.23 or later, it's a good idea to move to git switch because it avoids some tricky git checkout behaviors that have historically led beginners into trouble (and occasionally even tripped up Git experts). However, if you are used to git checkout, you can keep using it as long as you like, as it's still supported. The real problem is basically that git checkout was overly powerful and could destroy work unexpectedly. The new git switch is deliberately less-powerful and won't do that; the "destroy my work on purpose" operations were moved into git restore.
3It's possible to be on no branch, in what Git calls detached HEAD mode. If you use git checkout it can put you in this mode suddenly (though it prints a big scary warning, so if you don't see the scary warning, it didn't do that), but if you use git switch, you must allow detached-HEAD mode with git switch --detach. There's nothing wrong with this mode, you just need to be careful once you're in it, not to lose any new commits you make. It's easy to lose them if you're not careful. In normal mode, Git won't lose new commits like this.
如果处于分离HEAD模式，则没有上游——根据定义，因为没有分支——这个问题中的任何东西都不适用。
可达性
这部分有点技术性，我将把大部分内容外包给一个网站，Think Like (a) Git。在这里我将这样总结:分支名称(如main或xyzzy)和远程跟踪名称(origin/main, origin/xyzzy)是Git查找提交的方式。Git都是关于提交的。分支名称只在查找提交时起作用。当然，如果你找不到它们，你就有麻烦了，所以你的分支名称很重要。但关键是可达性，这是一个专业术语。
Git存储库中的每个提交都有编号，使用一个又大又丑的十六进制字母和数字字符串。这是提交的哈希ID, Git就是这样找到提交的。
每次提交都包含两件事:每个源文件的完整快照(以一种特殊的、压缩的、git化的和重复数据删除的形式)，以及关于提交本身的一些信息:例如，告诉谁做的、什么时候做的和为什么做的元数据(他们的日志消息)。在元数据中，每个提交都保存了一些先前提交的提交号。这意味着一个提交可以找到另一个更早提交。
正如Think Like (a) Git所指出的，这有点像火车。一旦你上了火车，它就会很好，在这种情况下，它会自动带你回到之前的所有火车站。但首先你得找到去火车站的路。Git分支名可以做到这一点:它保存了分支上最新提交的哈希ID。
我们可以这样画:
... <-F <-G <-H <--branch
分支名称分支保存了最新提交的哈希ID。我们说名称指向提交。不管哈希ID到底有多大，我们只是用字母H来代替它。
H是一个实际的提交，因此它有一个保存的快照(您的文件)和一些元数据。在元数据中，Git保存了之前提交的哈希ID。我们称其为早期提交G，我们说H指向G, Git可以通过分支名称指针找到H，这让Git可以访问提交，包括元数据，所以现在Git有了早期提交G的哈希ID。
G当然也是一个实际的提交:它有一个保存的快照和一些元数据。在G的元数据中，Git保存了之前提交F的哈希ID。我们说G指向F，现在Git可以使用这个保存的哈希ID找到F。
这将永远重复，或者更确切地说，直到我们完成第一次提交。该提交(假设我们在这里将其称为A)并不指向之前的提交，因为不存在更早的提交。
这个可达性的概念基本上是一个总结，如果我们从提交H开始(通过分支名称branch找到)，然后向后工作，会发生什么。我们到达提交H，提交G，提交F，依此类推。
分支名称和远程跟踪名称
正如我们刚刚注意到的，分支名称保存了一些提交的原始哈希ID。这让Git找到提交。不过，关于分支名称还有另一个特殊特性。
当你使用git checkout或git switch进入一个分支，然后进行新的提交时，git会自动更新分支名称存储的哈希ID。也就是说，假设我们有一系列这样的提交:
...--F--G--H <-- xyzzy (HEAD)
我们“在”xyzzy分支上，我喜欢给它加上一个特殊的名字HEAD。当图中有多个分支名称时，这很有用。注意H是目前最新的提交。但现在我们要做另一个，用通常的方法。
这个新的提交得到一个新的、唯一的、又大又丑的十六进制哈希ID，就像任何提交一样。Git确保新的提交向后指向提交H，因为这是我们用来进行新提交的提交。我们将使用字母I来表示这个新的提交。让我们画出来:
...--F--G--H <-- xyzzy (HEAD)
\
I
这张图实际上是在提交中:Git已经完成了I，但还没有完成Git的提交操作。问你自己这个问题:我们以后如何找到commit I ?我们需要它的哈希ID。我们可以在哪里存储哈希ID?
如果你说:在分支名称中，你是对的。事实上，正确的分支名称(至少就Git而言)就是您现在“使用”的那个。这就是我们在这幅图中所附的HEAD。现在，作为git提交的最后一部分，git将I的哈希ID写到xyzzy这个名字中。这就要求提交I，像这样:
...--F--G--H
\
I <-- xyzzy (HEAD)
现在图纸上没有扭结的原因了，所以我们可以把它理顺:
...--F--G--H--I <-- xyzzy (HEAD)
这就是分支名称的工作原理。说到底，这真的很简单:它只需要你同时思考几件事。名称查找提交。它查找最新的提交。从这里开始，Git向后工作，因为每次提交都会找到之前的提交。
那远程跟踪的名字呢?这里的技巧是你的Git与其他Git对话。每个Git都有自己的分支名称。你有你的主人或主人;他们有自己的。你有你的木树枝，他们也可以有他们的。
你的Git可以随时调用他们的Git，并询问他们的分支名称。但是，这并不是很有效，而且如果你与internet切断了联系，就不能工作。4在任何情况下，Git都不会这样做。相反，当您的Git调用他们的Git并从他们那里获得所有分支名称和哈希id的列表时，您的Git将获取这些名称和哈希id并将它们存储在存储库中。这发生在运行git fetch.5时
但是有一个问题。他们的main或master，或者xyzzy，如果他们有一个，并不一定意味着和你的main, master或xyzzy是一样的。解决方案很简单:Git只是获取它们的分支名称，并将其转换为您的远程跟踪名称。
如果origin的主或主或xyzzy移动了，你只需要运行git fetch或git fetch origin，也许用——prune。你的Git调用他们的Git。它们列出分支名称并提交哈希id。你的Git从他们那里获得任何新的提交，如果有必要:他们有，而你没有。然后，Git将它们的分支名称转换为远程跟踪名称，并创建或更新远程跟踪名称，以便在运行Git获取时记住它们的分支名称指向的位置。
If you use --prune, this handles the case where they deleted some branch name(s). Let's say they had a branch named oldstuff. You got it earlier so you have origin/oldstuff in your remote-tracking names. Then they deleted oldstuff, so this time they ... just don't have it any more. Without --prune, your Git ignores this. You keep your old origin/oldstuff even though it's dead now. With --prune, your Git says: Oh, huh, this looks dead now and prunes it away: a remote-tracking name in your Git that doesn't correspond to one of their branch names, just gets deleted.
修剪选项可能应该一直是默认的，但它不是，因此现在不能但是，您可以配置fetch。修剪为true并将其设置为默认值。
与2010年相比，这种情况在2021年并不常见。它在2005年Git首次发布时更为普遍。过去的情况是，比如说，在飞往Linux会议的航班上，你无论花多少钱都无法接入互联网。
选择取哪些名字，什么时候取，实际上是答案的一部分。随着时间的推移，它在git中发生了变化，并且仍然在发生一点点变化，尽管仍然存在各种限制。不过，我们不会讨论所有的细节。
git通常非常重视向后兼容性。它拿走了1。例如，将push.default的默认设置从匹配更改为简单。
git rev-list如何获得两个数字
前面，我注意到git状态打印的ahead、behind、latest或diverged消息是通过运行:
git rev-list --count --left-right $branch...$upstream
git rev-list在这里做的是统计可达提交。gitrevisions文档中描述的三点语法，产生了集合论中所谓的对称差分。然而，在非数学术语中，我们可以将其视为进行两次提交可达性测试，
我们可以这样画
I--J <-- xyzzy (HEAD)
/
...--G--H
\
K <-- origin/xyzzy
这里，提交J可以从分支名xyzzy到达，因为分支名指向那里。提交I可以从提交J到达，所以它也算数。这又回到了提交h，从图中可以看出，这有点特殊。
同时，可以通过远程跟踪名称origin/xyzzy访问提交K。提交H可以从k到达，从提交H开始，提交G和F等等都是可到达的。但是这两条“轨道”在提交H处连接起来:提交H和所有之前的提交都可以从这两个名称到达。
这使得I-J提交非常特殊，因为它们只能从名称xyzzy中访问，而K则非常特殊，因为它只能从名称origin/xyzzy中访问。三点表示法找到这些提交:只能从一个名称到达的提交，或者只能从另一个名称到达的提交。
如果我们把分支名称放在左边，把它的上游放在右边，并使用三点表示法，我们将找到这种情况下的所有这三个提交。使用——count使git的rev-list打印这个数字:3。使用——left-right可以让git rev-list变得更聪明:它应该计算因为左边名称(当前分支名称)而被计数的提交数，以及因为右边名称(上游)而被计数的提交数。所以有了这两个选项和三个点，我们得到:
2 1
作为输出，它告诉我们xyzzy上有两个提交不在origin/xyzzy上，还有一个提交在origin/xyzzy上，但不在xyzzy上。它们分别是提交j和i (xyzzy上)和K (origin/xyzzy上)。
如果没有——count选项，git rev-list将列出哈希id，前缀为<(左)或>(右)符号。使用git log代替git rev-list，如下所示:
git log --left-right xyzzy...origin/xyzzy
(再次注意这三个点:参见gitrevisions并搜索Symmetric Difference)我们将得到如图所示的三个提交，同样以<或>作为前缀。
这是一种查看哪些提交在分支上，哪些提交在上游上的简单方法。——decoration、——oneline和——graph通常更有用(在某些情况下，您可能还想添加——boundary)。
领先的，落后的，发散的或最新的
那么，假设我们运行:
git rev-list --count --left-right $branch...$upstream
(或者再次查看gitrevisions -使用右边的$branch@{upstream})并得到我们的两个计数。这些可以是:
0 and 0: Our branch name and our remote-tracking name (or whatever is in the upstream) point to the same commit. Nobody is ahead or behind. The git status command will say Your branch is up to date with '<upstream>'.
nonzero, zero: There are commits on the current branch that are not on the upstream. There are no commits on the upstream that are not on the current branch. So our branch is ahead of the upstream.
zero, nonzero: There are no commits on the current branch that are not on the upstream, but there are some on the upstream that are not on the current branch. This means our branch is behind the upstream.
nonzero, nonzero: This is like the diagram I drew above. Both the current branch and its upstream are simultaneously ahead-and-behind each other. The git status command will use the word diverged.
现在我们要回到最初的问题。让我们假设当前分支的上层是一个远程跟踪名称。注意，git rev-list获得的计数是基于远程跟踪分支名称中的内容。
这到底是怎么发生的呢?
在OP的场景中，只有一个人在进行新的提交，并使用git push发送它们。如果我是一个人，我可能会从GitHub克隆一些东西，然后做一个或两个新的提交，然后git push origin master。
在现代Git中，Git状态会告诉我我是最新的。在非常旧的Git版本中，Git状态现在会告诉我我的master在origin/master之前。原因很简单:在以前，git push无法更新origin/master。运行git fetch origin，或者只是git fetch，让你自己的git调用GitHub上的git，读取他们的信息，并意识到你的git推送已经工作了。
When you run git push, you have your Git call up some other Git. Your Git then offers the other Git any new commits you have, that they don't, that they'll need to complete the git push. They take those commits and put them somewhere.7 Then your Git asks their Git—politely asks, by default—if they would, please, if it's OK, set their branch name to refer to the latest commit, by its hash ID, as seen in your branch name. There's no remote-tracking stuff going on here. You are just asking them to set the same name you're using.
作为一般规则，如果您只是向他们的存储库添加新的提交，这种礼貌的请求会成功。如果你要求他们“丢失”一些提交，它就会失败:你会收到一个抱怨，说这是一个“非快进”。如果你是唯一一个向他们发送新提交的人，他们不应该有任何东西会以这种方式丢失，所以这应该总是有效的
如果推送失败，Git最好保持远程跟踪名称不变。你的Git从来没有从他们的Git中获得可以让你的Git更新它的信息。但如果成功了……好吧，他们只是将他们的分支名称设置为Git要求他们使用的哈希ID。现在Git知道它们的分支名称指向哪里了。Git应该更新远程跟踪名称。
在旧的Git版本中，你的Git根本不需要这么做。在Git版本1.8.2中，Git作者最终修复了这个问题:成功的Git推送会让Git更新远程跟踪名称，这是基于他们的Git同意Git提供的更新。所以这类事情不再经常发生了。
7:7从前光景不好的时候，人就直接放在库房里。在现代Git中，它们将它们放在隔离区域中，只有在实际接受新提交时才将它们迁移到存储库中。
当然，像GitHub这样的地方也提供了像受保护的分支这样的功能，比如对每一个推送都说不。我们还可以发明一些更奇特的场景，比如当你有多台计算机，你忘记了你通过计算机A进行了新的提交，现在尝试从计算机B进行提交。
如果你不是唯一一个做git push的人呢
假设Alice和Bob都克隆了一些GitHub存储库。这个存储库中的开发在分支dev上进行(用于开发)。所以Alice根据她的origin/dev制作了她自己的dev:
...--G--H <-- dev (HEAD), origin/dev [Alice's computer]
同样地，Bob也创造了自己的开发:
...--G--H <-- dev (HEAD), origin/dev [Bob's computer]
GitHub存储库开发也在H结束。(它们没有origin/dev: GitHub存储库不介意远程跟踪名称。)
Alice进行了一个新的提交，我们称之为I，然后在Alice的电脑上画出这样的图:
I <-- dev (HEAD)
/
...--G--H <-- origin/dev
与此同时，Bob进行了一个新的提交，我们称之为J:
...--G--H <-- origin/dev
\
J <-- dev (HEAD)
现在Alice和Bob都试图推动原始开发。他们中的一个先到达那里——可能是Alice:
...--G--H--I <-- dev [GitHub's systems]
Bob发送commit J到GitHub，看起来像这样:
I <-- dev
/
...--G--H
\
J ... polite request to set dev to J
如果GitHub这样做，这将“丢失”Alice的提交I，因为Git通过从名称开始并向后工作来查找提交。所以他们用“不是快进”的抱怨来拒绝这种推动。
Bob现在需要将提交I从GitHub拉到Bob自己的存储库中，这样Bob就可以看到:
I <-- origin/dev
/
...--G--H
\
J <-- dev (HEAD) [Bob's computer]
Bob应该用git fetch或git fetch origin来做这个，也许用——prune(或用fetch。修剪设置为true)。现在，当Bob运行git status时，他将得到“diverged”消息。
现在轮到鲍勃了，他是推举比赛的输家，他要弄清楚如何将他的工作(提交J)与爱丽丝的工作(提交I)结合起来。两个主要的是git merge和git rebase。我们不会在这里讨论谁应该做什么、什么时候做以及为什么做，只是说明当您认为自己严格领先于其他一些Git时，这是另一种可能陷入“分歧”状态的方式。
