更改存在于被跟踪的分支的上游,但是当我输入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

当前回答

让我们查看一个示例git repo,以验证您的分支(master)是否与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推送- 保存到存储库

状态告诉你的是,你在名为origin/master的ref后面,它是本地repo中的一个本地ref。在本例中,ref恰好跟踪某个名为origin的远程分支,但是状态并没有告诉您关于远程分支的任何信息。它告诉您有关ref的信息,这只是存储在本地文件系统上的一个提交ID(在这种情况下,它通常在本地repo中的一个名为.git/refs/remotes/origin/master的文件中)。

Git pull做了两个操作;首先,它执行一个git取回来更新远程repo中的提交(更新本地repo中的origin/master ref),然后它执行一个git合并来将这些提交合并到当前分支中。

在你执行取回步骤之前(无论是通过它自己还是通过git pull),你的本地回购无法知道上游是否有额外的提交,git状态只查看你的本地origin/master ref。

当git状态显示为“最新”时,它意味着“与当前分支跟踪的分支一起最新”,在这种情况下意味着“与称为origin/master的本地引用一起最新”。这只等同于“与上次取回的上游状态相一致”,而与“与上游的最新活动状态相一致”是不同的。

Why does it work this way? Well the fetch step is a potentially slow and expensive network operation. The design of Git (and other distributed version control systems) is to avoid network operations when unnecessary, and is a completely different model to the typical client-server system many people are used to (although as pointed out in the comments below, Git's concept of a "remote tracking branch" that causes confusion here is not shared by all DVCSs). It's entirely possible to use Git offline, with no connection to a centralized server, and the output of git status reflects this.

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

让我们查看一个示例git repo,以验证您的分支(master)是否与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中是这样。