状态告诉您的是，您在被调用的 ref 后面，origin/master 这是您本地 repo 中的本地 ref 。在这种情况下， ref
碰巧跟踪了某个远程分支中的分支，称为origin，但状态并未告诉您有关远程分支的任何信息。它告诉您 ref，它只是存储在本地文件系统上的提交
ID（在这种情况下，它通常位于.git/refs/remotes/origin/master本地 repo 中调用的文件中）。

git pull做两个操作；首先，它会git fetch更新远程仓库中的提交（更新origin/master本地仓库中的 ref），然后git merge将这些提交合并到当前分支中。

在您执行该fetch步骤（单独或通过git pull）之前，您的本地 repo 无法知道上游是否有其他提交，而git status只能查看您的本地origin/masterref。

当git status说 up-to-date
时，它​​的意思是“与当前分支跟踪的分支保持同步”，在这种情况下，这意味着“与本地引用保持同步origin/master”。这仅等同于“与我们上次执行时检索到的上游状态保持同步fetch”，这与“与上游的最新实时状态保持同步”不同。

为什么它会这样工作？那么这fetch一步可能是一个缓慢而昂贵的网络操作。Git（和其他 分布式
版本控制系统）的设计是为了避免不必要的网络操作，并且与许多人习惯的典型客户端-
服务器系统完全不同的模型（尽管正如下面评论中指出的那样，Git 的概念在这里引起混淆的“远程跟踪分支”并非由所有 DVCS 共享）。完全可以离线使用
Git，无需连接到集中式服务器， 的输出git status反映了这一点。

在 Git 中创建和切换分支（并检查它们的状态）应该是轻量级的，而不是对集中式系统执行缓慢的网络操作。设计 Git 和git status输出时的假设是用户理解这一点（太多的 Git 功能只有在你已经知道 Git 如何工作的情况下才有意义）。随着大量不熟悉 DVCS 的用户采用
Git，这个假设并不总是有效的。