git：您的分支领先于 X 次提交

...--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 commit 的最后一部分，Git 将 I 的哈希 ID 写入名称 xyzzy。这使得它指向提交 I，如下所示：

...--F--G--H
            \
             I   <-- xyzzy (HEAD)

现在图纸中没有任何扭结的原因，所以我们可以把它理顺：

...--F--G--H--I   <-- xyzzy (HEAD)

这就是分支名称的工作方式。最后，这真的很简单：它只需要你同时考虑几件事。该名称找到提交。它找到最新的提交。从那里开始，Git 向后工作，因为每个提交都会找到更早的提交。

远程跟踪名称呢？好吧，这里的诀窍是您的 Git 与其他 Git 对话。 每个 Git 都有自己的分支名称。你有你的master或main；他们有他们的。你有你的 xyzzy 分支，他们也可以有他们的。

您的 Git 可以随时、每次都调用他们的 Git，并询问他们的分支名称。但是，这不是很有效，而且如果您与 Internet 断开连接，也不会起作用。⁴ 无论如何，Git 不会这样做。相反，当您的 Git 调用他们的 Git 并从他们那里获取所有分支名称和哈希 ID 的列表时，您的 Git 会获取这些名称和哈希 ID 并将它们存储在 您的 存储库。当您运行 git fetch 时会发生这种情况。⁵

不过有问题。他们的 main 或 master，或者他们的 xyzzy（如果有的话）并不一定意味着 same 提交与 your main 或 master或xyzzy。不过解决方案很简单：Git 只需将它们的 branch 名称转换为您的 remote-tracking 名称。

如果 origin 的 main 或 master 或 xyzzy 已移动，您只需运行 git fetch 或 git fetch origin，也许与 --prune。你的 Git 调用他们的 Git。他们列出了他们的分支名称和提交哈希 ID。如有必要，您的 Git 会从他们那里获得任何新的提交：他们有的提交，而您没有。然后您的 Git 将它们的 branch 名称转换为您的 remote-tracking 名称并创建或更新您的远程跟踪名称以记住 their 分支名称指向的位置，此时您运行此 git fetch。

如果您使用 --prune，这将处理他们删除某些分支名称的情况。假设他们有一个名为 oldstuff 的分支。您之前得到它，所以您的远程跟踪名称中有 origin/oldstuff。然后他们删除了 oldstuff，所以这次他们......只是不再拥有它了。如果没有 --prune，您的 Git 会忽略这一点。你保留旧的 origin/oldstuff，即使它现在已经死了。 使用 --prune，您的 Git 会说：哦，呵呵，现在看起来已经死了并将其删掉：您的中的远程跟踪名称与他们的 branch 名称之一不对应的 Git 会被删除。

prune 选项可能应该一直是默认选项，但它不是，因此现在不能。⁶ 但是，您可以将 fetch.prune 配置为 true 和 make 它你的默认值。

4现在 2021 年的情况比 2010 年要少。在 2005 年 Git 首次发布时，这种情况要普遍得多。过去的情况是，例如，在飞往 Linux 会议的航班上，您无法以任何价格访问 Internet。

5选择取哪些名字，什么时候取名字，实际上是这里答案的一部分。它在 Git 中随着时间的推移发生了变化——并且仍在发生一点点变化——尽管仍然存在各种限制。不过，我们不会详细介绍所有细节。

⁶Git 通常非常重视向后兼容性。例如，从 1.x 到 2.0 的转换将 push.default 默认设置从 matching 更改为 simple。

git rev-list 如何获取这两个数字

早些时候，我注意到 git status 打印的提前、落后、最新或分歧消息来自运行：

git rev-list --count --left-right $branch...$upstream

git rev-list 在这里所做的是count 可访问的提交。 the gitrevisions documentation 中描述的三点语法产生集合论中称为对称差分的东西。但是，在非数学术语中，我们可以将其视为进行两次提交可达性测试，我们可以这样绘制：

          I--J   <-- xyzzy (HEAD)
         /
...--G--H
         \
          K   <-- origin/xyzzy

在这里，可以从您的分支名称 xyzzy 访问提交 J，因为名称指向那里。提交 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 更聪明，但是：它应该计算由于 left 名称而被计算的提交数—— 当前分支 名称——以及由于 正确 之一（上游）而计算了多少次提交。因此，通过这两个选项和三个点，我们得到：

2       1

作为输出，告诉我们 xyzzy 上的两个提交不在 origin/xyzzy 上，一个在 origin/xyzzy 上的提交不在 xyzzy 上。它们分别是提交 J-and-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）我们将看到三个提交，再次根据需要以 < 或 > 为前缀。

这是查看哪些提交在您的分支上以及哪些提交在上游的一种简单方法。它通常对 --decorate、--oneline 和 --graph 更有用（您可能在某些情况下也想添加 --boundary）。

领先、落后、分歧或最新

所以，假设我们已经运行：

git rev-list --count --left-right $branch...$upstream

（或者 - 再次参见 gitrevisions - 使用此处右侧的 $branch@{upstream}）并得到我们的两个计数。这些可以是：

0 和 0：我们的分支名称和远程跟踪名称（或上游中的任何名称）指向同一个提交。没有人领先或落后。 git status 命令会说 Your branch is up to date with ''。

非零，零：当前分支上有不在上游的提交。上游没有不在当前分支上的提交。所以我们的分支领先于上游。

零，非零：当前分支上没有不在上游的提交，但上游有一些不在当前分支上的提交。这意味着我们的分支在上游之后。

非零，非零：这就像我上面画的图。当前分支和它的上游都同时相互领先和落后。 git status 命令将使用发散这个词。

我们现在要跳回到最初的问题。假设当前分支的上游是一个远程跟踪名称。 请注意，git rev-list 获得的计数基于我们的远程跟踪分支名称中的内容。

这实际上是如何发生的？

在 OP 的场景中，只有一个人在进行新的提交并使用 git push 将它们发送出去。如果我是一个人，我可能会git clone GitHub 上的一些东西，然后进行一两次新的提交，然后 git push origin master。

在现代 Git 中，git status 会告诉我我是最新的。在非常旧的 Git 版本中，git status 现在会告诉我我的 master 领先于 origin/master。原因很简单：在过去，git push 未能更新 origin/master。运行 git fetch origin 或仅运行 git fetch，让您自己的 Git 在 GitHub 上调用 Git，阅读他们的信息，并意识到您的 git push 已经工作。

当您运行 git push 时，您的 Git 会调用其他 Git。然后，您的 Git 会向其他 Git 提供您拥有的任何新提交，而他们没有提交，他们需要完成 git push。他们接受这些提交并将它们放在某个地方。⁷ 然后你的 Git 会询问他们的 Git——默认情况下礼貌地询问——如果他们愿意，请设置 他们的 < strong>branch 名称，通过其哈希 ID 引用最新提交，如 您的 分支名称中所示。这里没有远程跟踪的东西。您只是要求他们设置您正在使用的同名。

作为一般规则，如果您只是向他们的存储库添加新提交，这种礼貌的请求会成功。如果你要求他们“丢失”一些提交，它会失败：你会抱怨这是一个“非快进”。如果你是唯一一个向他们发送新提交的人，他们不应该以这种方式失去任何东西，所以这应该总是有效的。8

如果推送失败，您的 Git 可以保持远程跟踪名称不变。你的 Git 从来没有从他们的 Git 那里得到信息，让你的 Git 更新它。但是如果推送成功......好吧，他们只是将他们的分支名称设置为您的 Git 要求他们使用的哈希 ID。所以现在你的 Git 知道他们的分支名称指向哪里。您的 Git 应该更新您的远程跟踪名称。

在旧的 Git 版本中，您的 Git 只是不打扰这样做。在 Git 版本 1.8.2 中，Git 作者最终解决了这个问题：成功的 git push 让您的 Git 更新您的远程跟踪名称，基于他们的 Git 同意您的 Git 提供的更新这一事实。所以这种事情不会再发生了。

7在过去糟糕的日子里，他们将它们直接放入自己的仓库中。在现代 Git 中，他们将它们放在隔离区，并且只有在他们真正接受新提交时才将它们迁移到他们的存储库中。

8当然，像 GitHub 这样的地方也提供了受保护的分支等功能，例如，它只是对每次推送说不。我们还可以创造更奇特的场景，例如当您拥有多台计算机并忘记您通过计算机 A 进行和推送新提交时，现在尝试从计算机 B 推送。

如果你不是唯一一个做 git push 的人怎么办

假设 Alice 和 Bob 都克隆了一些 GitHub 存储库。此存储库中的开发发生在分支 dev（用于开发）上。所以 Alice 从她的 origin/dev 中创建了自己的 dev：

...--G--H   <-- dev (HEAD), origin/dev  [Alice's computer]

同样，Bob 使 他的 成为自己的 dev：

...--G--H   <-- dev (HEAD), origin/dev  [Bob's computer]

GitHub 存储库 dev 也以 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 都尝试 git push origin dev。其中一个最先到达那里——也许是爱丽丝：

...--G--H--I   <-- dev  [GitHub's systems]

Bob 将提交 J 发送到 GitHub，如下所示：

          I   <-- dev
         /
...--G--H
         \
          J   ... polite request to set dev to J

如果 GitHub 会这样做，这将“丢失” Alice 的提交 I，因为 Git finds 提交是从名称开始并向后工作。因此，他们以“不是快进”的抱怨拒绝了推动。

Bob 现在需要将提交 I 从 GitHub 拉到 Bob 自己的存储库中，以便 Bob 看到：

          I   <-- origin/dev
         /
...--G--H
         \
          J   <-- dev (HEAD)  [Bob's computer]

Bob 应该使用 git fetch 或 git fetch origin，也许使用 --prune（或将 fetch.prune 设置为 true）来执行此操作。 现在当 Bob 运行 git status 时，他将收到“发散”消息。

现在由 Bob 作为推动竞赛的失败者来决定如何将 他的 工作（提交 J）与 Alice 的（提交 I）结合起来。有不同的方法可以组合工作。两个主要的是 git merge 和 git rebase。我们不会在这里讨论谁应该做什么、何时以及为什么要做，只是当你认为自己完全领先于其他 Git 时，这是另一种可能会陷入“分歧”状态的事实。