当上游存在更改时，为什么git status显示分支是最新的？

跟踪分支的上游存在更改，但是当我键入git status时表明我的本地分支是最新的。这是新的行为吗，我是否更改了配置设置，还是出了点问题？

谢谢您的帮助。

ubuntu@host:/my/repo# git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working directory clean


ubuntu@host:/my/repo# git pull
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (11/11), done.
remote: Total 11 (delta 6), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From bitbucket.org:my/repo
   1234567..abcdefg  master     -> origin/master
Updating 1234567..abcdefg
Fast-forward
 file1        |  1 -
 file2        | 43 +++++++++++++++++++++++++++++++++++++++++++
 file3        | 21 ++++++++++++---------
 file4        | 21 ++++++++++++---------
 4 files changed, 67 insertions(+), 19 deletions(-)
 create mode 100644 file5

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

git pull进行两次操作；首先，它执行a操作git fetch以使远程仓库中的提交保持最新（这将更新origin/master本地仓库中的引用），然后它执行a git merge来将那些提交合并到当前分支中。

直到您执行该fetch步骤（无论git pull是git status单独执行还是通过），您的本地存储库都无法知道上游还有其他提交，只能查看您的本地origin/master引用。

当git status说“最新”时，它表示“当前分支所跟踪的分支的最新”，在这种情况下，其意思是“使用称为origin/master“ 的本地引用更新”。这仅相当于“上一次我们上次获取的上游状态fetch的最新状态”，与“最新上游状态的最新状态”不同。

为什么这样工作？好吧，这fetch是一个潜在的缓慢且昂贵的网络操作。Git（和其他分布式版本控制系统）的设计是为了避免不必要的网络操作，并且与许多人习惯的典型客户端-服务器系统完全不同（尽管如下文注释中所指出的，Git的概念）导致混乱的“远程跟踪分支”的名称并非所有DVCS都共享。完全可以脱机使用Git，而无需连接到集中式服务器，而的输出git status反映了这一点。

在Git中创建和切换分支（并检查其状态）应该是轻量级的，而不是对集中式系统执行缓慢的网络操作的东西。设计Git和git status输出时的假设是用户理解这一点（太多的Git功能只有在您已经知道Git的工作原理时才有意义）。随着很多不熟悉DVCS的用户采用Git，这种假设并不总是正确的。

这是因为您的本地存储库尚未通过上游遥控器签入。要按照您的期望进行这项工作，请使用，git fetch然后git status再次运行。

虽然这些都是可行的答案，但我还是决定提供一种方法来检查本地存储库是否与远程存储（无论是获取还是提取）一致。为了查看我的分支在哪里，我简单地使用：

git remote show origin

它的作用是返回所有当前跟踪的分支，最重要的是-信息是否是最新的，位于远程起源分支之前还是之后。在上面的命令之后，这是返回的示例：

  * remote origin
  Fetch URL: https://github.com/xxxx/xxxx.git
  Push  URL: https://github.com/xxxx/xxxx.git
  HEAD branch: master
  Remote branches:
    master      tracked
    no-payments tracked
  Local branches configured for 'git pull':
    master      merges with remote master
    no-payments merges with remote no-payments
  Local refs configured for 'git push':
    master      pushes to master      (local out of date)
    no-payments pushes to no-payments (local out of date)

希望这对某人有帮助。

“源/主”是指向分支“源/主”的HEAD提交的引用。引用是对Git对象（通常是提交对象）的友好别名。仅当您git push访问远程服务器时，“源/主服务器”参考才会更新（http://git-scm.com/book/en/v2/Git-Internals-Git-References#Remotes）。

在项目的根目录中，运行：

cat .git/refs/remotes/origin/master

将显示的提交ID与以下内容进行比较：

cat .git/refs/heads/master

它们应该相同，这就是Git所说master的最新信息的原因origin/master。

当你跑步

git fetch origin master

这将在.git / objects文件夹下本地检索新的Git对象。并且Git更新.git / FETCH_HEAD，以便现在，它指向获取的分支的最新提交。

因此，要查看当前本地分支与从上游获取的分支之间的差异，可以运行

git diff HEAD FETCH_HEAD

让我们寻找到一个样品混帐回购协议，以验证是否your branch (master)是up to date有origin/master。

验证本地主机正在跟踪源/主机：

$ git branch -vv
* master a357df1eb [origin/master] This is a commit message

有关本地主分支的更多信息：

$ git show --summary
commit a357df1eb941beb5cac3601153f063dae7faf5a8 (HEAD -> master, tag: 2.8.0, origin/master, origin/HEAD)
Author: ...
Date:   Tue Dec 11 14:25:52 2018 +0100

    Another commit message

验证源/主服务器是否在同一提交上：

$ cat .git/packed-refs | grep origin/master
a357df1eb941beb5cac3601153f063dae7faf5a8 refs/remotes/origin/master

我们可以看到相同的哈希值，可以肯定地说，至少在当前的git repo中，该分支与远程分支是一致的。

尝试git add .之前git commit

琐碎的回答在某些情况下却很准确，例如把我带到这里的那个。我在一个对我来说是新的仓库中工作，我添加了一个状态不被视为新文件。

最终该文件与.gitignore文件中的模式匹配。

在这种情况下，使用git add并集成所有待处理文件，然后使用git commit和git push

git add-集成所有pedent文件

git commit-保存提交

git push-保存到存储库