在跟踪分支的上游存在更改，但是当我键入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
答案 0 :(得分：207)
状态告诉您的是，您位于名为origin/master 的裁判的后面，该裁判是本地仓库中的本地裁判。在这种情况下，ref恰好跟踪某个远程中的分支，称为origin，但状态不会告诉您有关远程分支的任何信息。它告诉你关于ref，它只是存储在本地文件系统上的提交ID（在这种情况下，它通常位于本地仓库中名为.git/refs/remotes/origin/master的文件中）。
git pull执行两项操作;首先，它使用git fetch来了解远程仓库中的提交（更新本地仓库中的origin/master ref），然后它会git merge合并这些提交进入当前的分支。
直到你执行fetch步骤（单独或通过git pull），您的本地仓库无法知道上游还有其他提交，而git status仅查看您当地的origin/master参考号
当git status表示最新时，它表示“与当前分支跟踪的分支最新”，在这种情况下意味着“与本地引用的最新信息称为” origin/master”。这仅仅等同于“上次我们执行fetch时检索到的上游状态的最新状态”，这与“与上游的最新实时状态保持同步”不同。
为什么这样工作？那么fetch步骤是一个潜在的缓慢而昂贵的网络操作。 Git（和其他distributed version control systems）的设计是为了在不必要的时候避免网络操作，并且是与许多人习惯的典型客户端 - 服务器系统完全不同的模型（尽管如下面的评论中指出的那样，Git的导致混淆的“远程跟踪分支”的概念并非由所有DVCS共享。完全可以离线使用Git，不与中央服务器连接，git status的输出反映了这一点。
在Git中创建和切换分支（并检查它们的状态）应该是轻量级的，而不是对集中式系统执行慢速网络操作的东西。设计Git和git status输出时的假设是用户理解这一点（如果你已经知道Git是如何工作的，那么Git功能太多才有意义）。由于许多不熟悉DVCS的用户采用Git，这种假设并不总是有效。
答案 1 :(得分：27)
这是因为您的本地仓库尚未使用上游遥控器签入。要按照您的预期进行操作，请使用git fetch然后再次运行git status。
答案 2 :(得分：4)
尽管这些都是可行的答案，但我还是决定给出一种方法来检查本地存储库是否与远程存储（无论是获取还是提取）一致。为了查看我的分支在哪里，我简单地使用：
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)
希望这对某人有帮助。
答案 3 :(得分：4)
我也遇到了类似的问题，我在网上到处搜索解决方案，并尝试遵循这些解决方案。没有人为我工作。这些是我解决该问题的步骤。
制作新的存储库，然后将现有代码再次推送到新的存储库
如果您的存储库中已经有一个.git /文件夹，则git init不会初始化。因此，对于您的情况，请-
（1）rm -rf .git /
（2）git init
（3）git remote add origin https://repository.remote.url
（4）git commit -m“提交消息”
（5）git push -f原始主机
请注意，此存储库的所有git配置（如远程存储库）在步骤1中均已清除。因此，您必须再次设置所有远程存储库URL。
另外，请注意第5步中的-f：遥控器已经具有一些带有n个提交的代码库，并且您试图将所有这些更改合并为一个提交。因此，有必要将更改强制推到远程。
答案 4 :(得分：1)
在这种情况下，请使用git add并整合所有待处理文件，然后使用git commit和git push
git add-整合所有pedent文件
git commit-保存提交
git push- 保存到存储库
答案 5 :(得分：0)
＆＃34;来源/主＆＃34;指的是对分支＆＃34; origin / master＆＃34;的HEAD提交的引用。
引用是Git对象的人性化别名，通常是提交对象。
＆＃34;来源/主＆＃34;当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答案 6 :(得分：0)
让我们看一个样本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中，该分支与远程分支是一致的。
答案 7 :(得分：0)
临时性回答在某些情况下仍然很准确，例如将我带到这里的那个。 我正在使用对我来说是新的存储库，并添加了一个状态不视为新文件。
最终该文件与.gitignore文件中的模式匹配。