为什么当上游存在变更时git状态显示分支是最新的?

更改存在于被跟踪分支的上游，但当我键入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
205242 次浏览
小开

这是因为您的本地回购还没有与上游遥控器进行检查。为了让它像你期望的那样工作，使用git fetch，然后再次运行git status。

小开
最佳答案

状态告诉你的是你在名为origin/master 哪个是本地回购中的本地参考的ref后面。在这种情况下，ref恰好跟踪了某个名为origin的远程分支，但是状态并没有告诉你任何关于远程分支的信息。它告诉你有关ref的信息，ref只是存储在本地文件系统上的一个提交ID(在这种情况下，它通常在本地repo中名为.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版本控制系统)的设计是为了避免不必要的网络操作，并且是一个与许多人习惯的典型客户-服务器系统完全不同的模型(尽管在下文中评论中指出，Git的“远程跟踪分支”概念在这里引起混淆，并不是所有DVCSs都共享)。在没有连接到中央服务器的情况下，完全可以脱机使用Git， git status的输出反映了这一点。

在Git中创建和切换分支(以及检查它们的状态)应该是轻量级的，而不是对集中式系统执行缓慢的网络操作。设计Git和git status输出时的假设是用户理解这一点(如果你已经知道Git是如何工作的，那么太多的Git特性才有意义)。随着越来越多不熟悉DVCS的用户采用Git，这种假设并不总是有效的。

小开

“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

Compare the displayed commit ID with:

cat .git/refs/heads/master

它们应该是相同的，这就是为什么Git说master与origin/master是最新的。

当你奔跑

git fetch origin master

That retrieves new Git objects locally under .git/objects folder. And Git updates .git/FETCH_HEAD so that now, it points to the latest commit of the fetched branch.

So to see the differences between your current local branch, and the branch fetched from upstream, you can run

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

验证origin/master是否在同一个提交上:

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

我们可以看到相同的散列，并且可以肯定地说分支与远程分支是一致的，至少在当前的git 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)

希望这能帮助到一些人。

小开

琐碎的答案，但在某些情况下是准确的，比如带我来这里的那个。 我在一个回购工作，这对我来说是新的，我添加了一个文件，这个文件在状态上并不被视为新的

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

小开

在这种情况下，使用git添加和集成所有挂起的文件，然后使用git commit和git push

Git添加-集成所有暂存文件

Git提交-保存提交

git push - 保存到存储库

小开

我也遇到过类似的问题，我在网上到处搜索解决方案，并试图遵循它们。没有一个对我有效。这些是我针对这个问题采取的步骤。

创建新的repo并将现有代码再次推到新的repo

如果您的存储库中已经有. Git /文件夹，则Git init不会初始化。所以，就你的情况来说，做

(1) rm -rf .git/

(2) git init

(3) git远程添加origin https://repository.remote.url

(4) git commit -m“提交信息”

(5) git push -f origin master

请注意，所有git配置，如该存储库的远程存储库，都将在步骤1中清除。因此，您必须重新设置所有远程存储库url。

另外，注意第5步中的-f:远程已经有n次提交的一些代码库，您试图将所有这些更改都提交到一次提交中。因此，强制将更改推到远程是必要的。

小开

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


提交答案