更改存在于被跟踪的分支的上游,但是当我输入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后面,它是本地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并将现有代码再次推到新的repo

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

(1) rm -rf .git/

2)滚英寸

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

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

(5) git push -f origin master

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

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

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

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

Git提交-保存提交

Git推送- 保存到存储库

这个答案微不足道,但在某些情况下是准确的,比如让我来到这里的那个问题。 我在一个回购工作,这对我来说是新的,我添加了一个文件,这不是新的状态。

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

虽然这些都是可行的答案,但我决定给出我的方法来检查本地回购是否与遥控器一致,而不需要取回或拉取。为了看到我的分支在哪里,我简单地使用:

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)

希望这能帮助到一些人。