【问题标题】:git pull error :error: remote ref is at but expectedgit pull 错误:错误:远程参考在但预期
【发布时间】:2012-08-01 13:16:06
【问题描述】:

完整信息:

error: Ref refs/remotes/origin/user is at 3636498c2ea7735fdcedc9af5ab3c8689e6abe77 but expected a21359c6cc2097c85775cde6a40105f4bd7100ec
From github.com:{github project url}
 ! a21359c..6273ffc  user -> origin/user  (unable to update local ref)

【问题讨论】:

  • 显然有人用git push --force重写了存储库的历史记录。尝试运行git pull --force
  • 用 git push --force 给出同样的错误
  • 回答这个问题解决了这个错误 - stackoverflow.com/questions/3046436/…

标签: git pull git-pull


【解决方案1】:

如果您在不区分大小写的文件系统(Windows 或 OS X)下运行 git,如果有两个名称相同但大小写不同的分支,例如user_model_changesUser_model_changes 因为两个远程分支都将匹配相同的跟踪参考。

删除错误的远程分支(你不应该有只区分大小写的分支)然后git remote prune origin,一切都应该正常

【讨论】:

  • 感谢您的回答。这不是这个错误的问题。我已经找到了这个问题的解决方案,并在问题下方发表了评论。
  • 对 Mac OS X 也有帮助(默认文件系统不区分大小写)。
  • 是的,Windows 上不区分大小写的问题导致了该问题。我通过手动删除.git\refs\remotes\origin 文件夹中的引用然后再次git pull 来修复它。
  • 对于那些不知道 .git 文件夹在哪里的人。它将在您的项目/工作空间文件夹中创建:D
  • 这是一个git bug。(至少错误信息是错误的)。我希望有人可以将此错误报告给 git 项目。我看起来很难向 git 项目报告错误。 github.com/git/git
【解决方案2】:

永久修复

git update-ref -d 解决了我的这个错误实例,例如

git update-ref -d refs/remotes/origin/user

请注意,这不会影响远程。

在我的情况下,随后的git fetch 再次获取了该分支,并且在 git fetches/pulls 之后不再给出错误“远程引用在但预期”。

如果这不起作用,临时修复:

还请注意,如果您不关心相关分支(例如,您只想更新 master,而不是 origin/user),git pull 解决方法是获取然后合并您关心的特定分支,例如

git fetch # may give an error for a particular branch, but other branches will still be successfully fetched
git merge origin/master

【讨论】:

  • 这应该是公认的解决方案,因为它无需触摸遥控器即可解决问题。
  • 这让我更深入地进行了交换。之后做git rebase --continue 我得到fatal: Needed a single revision. Cannot read HEAD
  • 最佳答案(永久修复)。您没有触摸远程,随后的 git pull 再次获取分支。
【解决方案3】:

只需删除\.git\refs\remotes\origin下的文件夹和文件即可。 工作,当你没有未推送的更改时。

【讨论】:

  • 如果您的远程 ref 被“打包”并因此不在 refs/remotes/** 中,这可能不起作用,那么 @JDiMatteo 的解决方案应该仍然有效
  • 为我工作。非常感谢!
  • 当我这样做,然后进行拉取时,\.git\refs\remotes\origin 下的所有已删除文件都会返回,并且在随后的拉取中,我会得到同样的错误。这是一个循环。我所做的只是删除本地副本并克隆一个新副本。这对我有用。
  • 为我工作。谢谢。
【解决方案4】:

以下两条命令一一使用。

git gc --prune=now

git remote prune origin

这将解决您的问题。

【讨论】:

  • 这对我有用,但是当我做另一个 git pull 时,这个问题又出现了
  • @Jojin 和你一样。而我最终选择了 Prakash Saravanan 提供的方式
  • 这应该高于编辑 git 文件的建议 :)
  • 该解决方案也对我有用。您能否解释一下这些命令的具体作用,以及我们为什么需要使用这些命令?
【解决方案5】:

我运行这个来解决问题:

git gc --prune=now

【讨论】:

  • 这为我解决了这个问题。
  • 对我来说也是 ..-- :)
  • 谢谢,这个解决方案为我修复。您能否详细说明您提供的解决方案。
  • 基本上它只是一个 git 垃圾收集器工具,因此它会擦除任何不同步但在本地计算机上用于缓存目的的内容
【解决方案6】:

我必须从我的命令行中删除我的 分支

.git\refs\remotes\{my remote}\{**my branch**}

然后手动做:

git pull [remote_name] [branch_name]

我能够提取更改。

注意:我使用的是 SourceTree 并且无法进行拉取。

【讨论】:

  • 最终我重命名了我的遥控器:我的 SourceTree 历史记录中有两个遥控器“Bitbucket/staging”和“bitbucket/staging”,但在执行操作时只有“Bitbucket”出现在命令行中:git remote -v .所以我将Bitbucket重命名为bitbucket,冲突终于消失了,希望这对最有可能的SourceTree用户有所帮助。
  • 在为我修复之前,我还必须从 .git\packed-refs 中删除分支。
【解决方案7】:

硬重置也可以解决问题

git reset --hard origin/master

【讨论】:

  • 您选择了最佳答案吗?
  • 这是我认为最好和最简单的答案。 git reset --hard
  • 虽然这将解决问题,但我还想提醒用户,当您在分支中有尚未推送到远程的本地提交时执行此命令将基本上清除那些本地提交(但是,这些仍然可以使用 git reflog 检索一段时间)
【解决方案8】:

更清晰的步骤

  1. 在终端中

    cd /.git/refs/remotes/origin
    
  2. ls,你会看到一些分支HEAD

  3. 删除你认为有问题的分支

    rm branchname
    
  4. 如果不起作用,请删除所有分支/HEAD

    • 你可能想拉

希望它现在可以工作。

【讨论】:

  • 这和git update-ref -d <branchname>本质上是一样的吗?
【解决方案9】:

不幸的是,像 prune 和 reset 或 push 这样的 GIT 命令对我不起作用。 Prune 工作了一次,然后问题又回来了。

对我有用的永久解决方案是手动编辑 git 文件。只需转到项目的 .git 文件夹,然后在 Notepad++ 等文本编辑器中打开文件 packed-refs。然后导航到失败分支所在的行,并将其 guid 更新为预期的。

如果你有这样的消息:

错误:无法锁定 ref 'refs/remotes/origin/feature/branch_xxx':位于 425ea23facf96f51f412441f41ad488fc098cf23 但预期为 383de86fed394ff1a1aeefc4a522d886adcecd79

然后在文件中找到带有refs/remotes/origin/feature/branch_xxx 的行。那里的向导将是预期的(第二个)一个-383de86fed394ff1a1aeefc4a522d886adcecd79。您需要将其更改为真正的(第一个)-425ea23facf96f51f412441f41ad488fc098cf23

重复其他失败的分支,你会很好地继续。有时在重新获取后,我不得不重复我之前已经“修复”过的相同分支。在重新获取 GIT 时更新 guid 并为您提供最新的。

无论如何,问题不是阻碍。分支列表得到更新。这是一个警告。

【讨论】:

    【解决方案10】:

    试试这个,它对我有用。 在您的终端中:git remote prune origin

    【讨论】:

      【解决方案11】:

      git for-each-ref --format='delete %(refname)' refs/original | git update-ref --stdin git reflog expire --expire=now --all git gc --prune=now

      【讨论】:

        【解决方案12】:

        我遇到了同样的问题,因为即使我已经推送到远程分支,我也重置为较旧的提交。

        我通过删除本地分支然后检查源分支git checkout origin/my_branch 然后执行git checkout my_branch 解决了这个问题

        【讨论】:

        • 这是轻松摆脱其他麻烦的最佳方法之一。你总是有一个新的开始。为我工作。
        【解决方案13】:

        这里的情况相同,但没有关于 cmets 发布它在我的情况下是正确的,我只有一个分支(主)并且只使用 Unix 文件系统,当我运行 git fetch --progress --prune origin 和分支在前面或“原点/主”。没有人可以提交,只有 1 个用户可以推送。

        注意:我在 acme 存储库中有一个子模块,并且 acme 有新的子模块更改(新提交),我需要首先使用 git submodule update 进行子模块更新。

        [2014-07-29 13:58:37] Payload POST received from Bitbucket
        [2014-07-29 13:58:37] Exec: cd /var/www/html/acme
        ---------------------
        [2014-07-29 13:58:37] Updating Git code for all branches
        [2014-07-29 13:58:37] Exec: /usr/bin/git checkout --force master
        [2014-07-29 13:58:37] Your branch is ahead of 'origin/master' by 1 commit.
        [2014-07-29 13:58:37]   (use "git push" to publish your local commits)
        [2014-07-29 13:58:37] Command returned some errors:
        [2014-07-29 13:58:37] Already on 'master'
        ---------------------
        [2014-07-29 13:58:37] Exec: /usr/bin/git fetch --progress --prune origin
        [2014-07-29 13:58:39] Command returned some errors:
        [2014-07-29 13:58:39] error: Ref refs/remotes/origin/master is at 8213a9906828322a3428f921381bd87f42ec7e2f but expected c8f9c00551dcd0b9386cd9123607843179981c91
        [2014-07-29 13:58:39] From bitbucket.org:acme/acme
        [2014-07-29 13:58:39]  ! c8f9c00..8213a99  master     -> origin/master  (unable to update local ref)
        ---------------------
        [2014-07-29 13:58:39] Unable to fetch Git data
        

        要解决这个问题(在我的例子中),如果你的分支领先于原点,只需运行第一个 git push。

        【讨论】:

        • 您在这里的回答仅与您的本地存储库在新提交后领先于原点这一事实有关。这是本地 git commit 操作的自然状态,与原始问题无关。
        【解决方案14】:

        我知道这是旧的,但我有自己的修复。因为我使用的是源代码树,所以发生此错误是因为有人创建了一个新分支。源代码树对此感到困惑。在我按下“要拉取的远程分支”组合框旁边的“刷新”按钮后,似乎sourcetree已经更新了分支列表,现在我可以拉取成功了。

        【讨论】:

          【解决方案15】:

          我遇到了同样的问题,我刚刚删除了远程分支并从主分支创建了新分支,并将我的更改从旧功能分支合并到新功能分支。现在我尝试了拉取和推送请求,它对我有用

          【讨论】:

            【解决方案16】:

            在不断搜索之后,这是对我有用的解决方案,它需要取消设置/删除上游

            git branch --unset-upstream
            

            【讨论】:

              猜你喜欢
              • 2015-03-07
              • 2014-08-18
              • 2012-04-21
              • 1970-01-01
              • 2014-07-29
              • 2015-01-25
              • 2012-06-17
              • 2013-11-12
              • 1970-01-01
              相关资源
              最近更新 更多