状态告诉你的是你在一个叫做origin/master * 的引用后面，这个引用是你本地repo* 中的一个本地引用。在这种情况下，引用碰巧跟踪了某个叫做origin的远程库中的一个分支，但是状态并没有告诉你关于远程库中的分支的任何信息，它告诉你的是引用，它只是存储在你本地文件系统中的一个提交ID（在本例中，它通常位于本地存储库中名为.git/refs/remotes/origin/master的文件中）。
git pull执行两个操作;首先，它执行git fetch来更新远程存储库中的提交（更新本地存储库中的origin/master引用），然后它执行git merge来将这些提交合并到当前分支中。
在您执行fetch步骤之前（无论是自己执行还是通过git pull执行），您的本地repo都无法知道上游还有其他提交，并且git status只查看您的本地origin/master ref。
当git status说up-to-date时，它意味着“与当前分支跟踪的分支最新”，这在本例中意味着“与称为origin/master的本地引用最新“。这仅等同于“与上次我们执行fetch时检索到的上游状态最新“，这与“与fetch最新”不同。具有上游的最新活动状态的日期”。
为什么它是这样工作的？fetch步骤是一个潜在的缓慢和昂贵的网络操作。Git的设计（以及其他distributed version control systems）是为了避免不必要的网络操作，并且是与许多人习惯的典型客户机-服务器系统完全不同的模型（尽管正如下面的评论所指出的，Git的“远程跟踪分支”概念在这里引起了混乱，但并不是所有DVCS都认同这一点）离线使用Git是完全可能的，没有连接到中央服务器，git status的输出反映了这一点。
创建和切换分支（并检查它们的状态）应该是轻量级的，而不是对集中式系统执行缓慢的网络操作的东西。设计Git时的假设，以及git status输出，是用户明白这一点（如果你已经知道Git的工作原理，那么太多的Git特性才有意义）。随着越来越多不熟悉DVCS的用户采用Git，这种假设并不总是有效的。

这是因为您的本地存储库尚未签入到上游远程存储库。要使此操作如您所期望的那样工作，请使用git fetch，然后再次运行git status。

虽然这些都是可行的答案，但我决定给予一种方法来检查本地repo是否与远程repo一致，而不需要提取或拉取。为了查看分支在哪里，我简单地使用：

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)

希望这能帮到什么人。

我也曾遇到过类似的问题，我在网上到处寻找解决方案，并努力遵循它们，但没有一个对我有效。这些就是我解决问题的步骤。
创建新的存储库并将现有代码再次推送到新的存储库
如果你的仓库中已经有了. git/文件夹，git init就不会初始化。所以，对于你的情况，请-
(1)rm-射频git/
(2)git初始化
(3)git远程添加原点https://repository.remote.url
(4)git commit-m "提交消息"
(5)git push-f原始主机
请注意，所有git配置（如远程仓库）在步骤1中已经被清除，因此，您必须再次设置所有远程仓库的URL。
另外，注意步骤5中的-f：remote已经有了一些包含n次提交的代码库，而您正试图将所有这些更改放到一次提交中，因此，强制推送更改到remote是必要的。

"origin/master"引用指向分支"origin/master"的HEAD提交的引用。引用是Git对象（通常是提交对象）的人性化别名。"origin/master"引用仅在您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/FETCH_HEAD，使其指向所获取分支的最新提交。
因此，要查看当前本地分支与从上游获取的分支之间的差异，可以运行

git diff HEAD FETCH_HEAD

让我们看一个示例git repo来验证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中是这样。

琐碎的答案，但在某些情况下准确，如一个带我来这里。我在回购工作，这对我来说是新的，我添加了一个文件，这是不被视为新的状态。
最后，该文件与.gitignore文件中的模式匹配。

在本例中，使用git add并集成所有挂起的文件，然后使用git commit，再使用git push
git add -集成所有pedent文件
git commit -保存提交
git push -保存到仓库

导致这个错误的原因是在错误的文件夹中执行git status ...检查这个。