您的配置指定与远程的 <branch name> 合并，但没有获取这样的 ref。？
我收到这个错误拉：
您的配置指定与远程的 ref 'refs/heads/feature/Sprint4/ABC-123-Branch' 合并，但没有获取这样的 ref。
任何其他分支都不会出现此错误。这个分支的特别之处在于它是从另一个分支的先前提交创建的。我的配置文件如下所示：
[core]
repositoryformatversion = 0
filemode = false
bare = false
logallrefupdates = true
symlinks = false
ignorecase = true
hideDotFiles = dotGitOnly
[remote "origin"]
url = <url here>
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "new-develop"]
remote = origin
merge = refs/heads/new-develop
[branch "feature/Sprint4/ABC-123-Branch"]
remote = origin
merge = refs/heads/feature/Sprint4/ABC-123-Branch
这意味着什么
您的上游（称为 origin 的远程）不再有，或者可能从未有过（仅凭此信息无法判断）名为 feature/Sprint4/ABC-123-Branch 的分支。有一个特别常见的原因：有人（可能不是你，或者你记得）删除了另一个 Git 存储库中的分支。
该怎么办
这取决于你想要什么。请参阅下面的讨论部分。你可以：
在远程创建或重新创建分支，或者
删除您的本地分支，或
你能想到的任何其他东西。
讨论
您必须正在运行 git pull（如果您正在运行 git merge，您将收到不同的错误消息或根本没有错误消息）。
当您运行 git fetch 时，您的 Git 会根据您的配置的 [remote "origin"] 部分下的 url 行联系另一个 Git。该 Git 运行一个命令 (upload-pack)，其中包括向 your Git 发送所有分支的列表。您可以使用 git ls-remote 来了解它是如何工作的（试试看，它很有教育意义）。这是我在 git 本身的 Git 存储库上运行它时得到的片段：
$ git ls-remote origin
From [url]
bbc61680168542cf6fd3ae637bde395c73b76f0f HEAD
60115f54bda3a127ed3cc8ffc6ab6c771cbceb1b refs/heads/maint
bbc61680168542cf6fd3ae637bde395c73b76f0f refs/heads/master
5ace31314f460db9aef2f1e2e1bd58016b1541f1 refs/heads/next
9e085c5399f8c1883cc8cdf175b107a4959d8fa6 refs/heads/pu
dd9985bd6dca5602cb461c4b4987466fa2f31638 refs/heads/todo
[snip]
refs/heads/ 条目列出了遥控器上存在的所有分支，1 以及相应的提交 ID（对于 refs/tags/ 条目，ID 可能指向标记对象而不是提交）。
您的 Git 会根据同一 remote 部分中的 fetch 行获取每个分支名称并更改它。例如，在这种情况下，您的 Git 将 refs/heads/master 替换为 refs/remotes/origin/master。您的 Git 对遇到的每个分支名称都执行此操作。
它还在特殊文件 FETCH_HEAD 中记录了原始名称（如果您查看自己的 .git 目录，可以看到此文件）。此文件保存获取的名称和 ID。
git pull 命令是一种方便快捷的方式：它在适当的远程上运行 git fetch，然后运行 git merge（或者，如果有指示，git rebase）与合并（或变基）所需的任何参数) 按照 [branch ...] 部分的指示。在这种情况下，您的 [branch "feature/Sprint4/ABC-123-Branch"] 部分表示从 origin 获取，然后与在名称 refs/heads/feature/Sprint4/ABC-123-Branch 下找到的任何 ID 合并。
由于在该名称下没有找到任何内容，git pull 抱怨并停止。
如果您将此作为两个单独的步骤运行，git fetch 和 git merge（或 git rebase），您的 Git 将查看缓存的 remotes/origin/ 远程跟踪分支，以查看要合并或变基的内容。如果一次有这样一个分支，您可能仍然拥有远程跟踪分支。在这种情况下，您不会收到错误消息。如果从来没有这样的分支，或者如果您使用 --prune 运行 git fetch（删除死的远程跟踪分支），那么您没有相应的远程跟踪分支，您会收到投诉，但它会请参阅 origin/feature/Sprint4/ABC-123-Branch。
无论哪种情况，我们都可以得出结论，在名为 origin 的遥控器上现在不存在 feature/Sprint4/ABC-123-Branch。
它可能曾经存在过，并且您可能从远程跟踪分支创建了本地分支。如果是这样，您可能仍然拥有远程跟踪分支。您可能会调查以查看谁从远程删除了分支，以及为什么，或者您可能只是推送某些内容以重新创建它，或删除您的远程跟踪分支和/或本地分支。
1好吧，至少它会承认的一切。但除非他们特别隐藏了一些参考文献，否则该列表包括所有内容。
编辑，2020 年 7 月：有一个新的 fetch 协议可以避免列出所有内容，并且只列出 Git 说它正在寻找的名称。这可以帮助具有大量分支和/或标签的存储库。但是，如果您的 Git 对所有可能的名称感兴趣，您仍然会在此处获得所有名称。
如果您/某人重命名了分支，也会发生这种情况。所以请按照以下步骤操作（如果您知道分支名称已重命名）假设较早的分支名称为 wrong-branch-name 并且有人将其重命名为 correct-branch-name 所以。
git checkout correct-branch-name
git pull（您会看到“您的配置指定..”）
git branch --unset-upstream
git branch --set-upstream-to=origin/correct-branch-name
对于较旧的 git 版本 git push --set-upstream origin correct-branch-name
git pull（您不会收到之前的消息）
git push 甚至没有必要，如果当前分支位于其远程之后，它将无法工作。 git pull origin correct-branch-name 就足够了。
检查您的远程分支是否可以拉取。我有同样的问题，终于意识到远程分支被某人删除了。
这是一个更常见的错误，因为许多项目正在将其 master 分支移动到另一个名称，如 main、primary、default、root、reference、latest 等，如在Github plans to replace racially insensitive terms like ‘master’ and ‘whitelist’。
要修复它，首先找出项目现在正在使用什么，您可以通过他们的 github、gitlab 或其他 git 服务器找到。
然后执行此操作以捕获当前配置：
$ git branch -vv
...
* master 968695b [origin/master] Track which contest a ballot was sampled for (#629)
...
找到描述 master 分支的行，并注意远程存储库是否称为 origin、upstream 或其他名称。
然后使用该信息，将分支名称更改为新名称，例如，如果它说您当前正在跟踪 origin/master，则替换为 main：
git branch master --set-upstream-to origin/main
您还可以重命名自己的分支以避免将来混淆：
git branch -m main
git fetch upstream、git checkout main，然后是下一次 git pull。
对我来说，这是一个区分大小写的问题。我的本地分支是 Version_feature2 而不是 Version_Feature2。我使用正确的大小写重新检查了我的分支，然后 git pull 工作。
您可以通过运行以下命令轻松地将本地分支与远程分支链接：
git checkout <your-local-branch>
git branch --set-upstream-to=origin/<correct-remote-branch> <your-local-branch>
git pull
当实际原因是我的磁盘已满时，我遇到了类似的错误。删除一些文件后，git pull 开始按预期工作。
在我的情况下，我只是缺少远程分支上的初始提交，因此本地分支没有找到任何要拉的东西，它给出了那个错误消息。
我做了：
git commit -m 'first commit' // on remote branch
git pull // on local branch
当原始分支名称有一些大小写问题时，也会收到此错误。
例如：origin 分支为 team1-Team，本地分支已结帐为 team1-team。那么，-Team 中的 T 和 -team 中的 t 可能会导致此类错误。这发生在我的案例中。因此，通过将本地名称更改为原始分支的名称，错误就解决了。
我发现从默认 master 分支已重命名为 main 的存储库中提取更新时经常发生此错误。在 2020 年将 master 分支重命名为 main 分支的趋势之后，经常遇到这种情况。
因此，如果您之前使用默认的 master 分支克隆了一个 repo，并且该分支已重命名为 main，则一种修复方法是将上游从 master 指向 main：
git branch --set-upstream-to=origin/main master
如果该命令成功，您应该会看到如下消息：
分支“master”设置为从“origin”跟踪远程分支“main”。
然后，您可以使用 git branch -m master main 将本地分支从 master 重命名为 main（与远程分支名称保持一致）
我一直遇到这个问题。就我而言，@Jerreck 关于分支名称大小写差异的评论是导致此错误的原因。某些 Windows 工具不区分大小写。
要在 git 中关闭区分大小写，请运行以下命令：
git config --global core.ignorecase true
请注意，这将影响的不仅仅是分支名称。例如，如果您在同一目录中有“Foo.h”和“foo.h”（在为 Windows 构建软件时不是一个好主意），那么我怀疑您不能关闭区分大小写。
core.ignorecase 选项只会影响您的文件，但不会影响 git 内部文件（位于 .git 文件夹中）
core.ignorecase true 对我不起作用（问题是分支名称的大小写不同）。所以我刚刚将上游设置为正确的分支名称
我在 master/main 分支上遇到了类似的问题。就我而言，我的硬盘上没有足够的可用空间。释放一些空间后，它起作用了。
我假设它是因为文件 /.git 需要一些空间来编辑其文件。例如文件：'refs/heads/feature/Sprint4/ABC-123-Branch'
检查区分大小写
就我而言，我的分支名称（远程）使用大写字母，例如：BranchName。不小心，我在本地机器上创建了一个分支branchname（全小写）并将上游设置为相同，并且出现了这个错误。
解决方案：我删除了本地存储库，再次克隆它，然后签出到 BranchName
就我而言，我删除了当前分支所源自的原始分支。所以在 .git/config 文件中我有：
[branch "simil2.1.12"]
remote = origin
merge = refs/heads/simil2.0.5
rebase = false
simil2.0.5 被删除。我用相同的分支名称替换它：
[branch "simil2.1.12"]
remote = origin
merge = refs/heads/simil2.1.12
rebase = false
它奏效了
就我而言，我重命名了 Github 上的分支，作为回报，它告诉我执行以下命令：
默认分支已重命名！
main is now named <new_name>
如果你有一个本地克隆，你可以通过运行来更新它：
git branch -m main <new_name>
git fetch origin
git branch -u origin/<new_name> <new_name>
git remote set-head origin -a
对我来说，发生这种情况是因为我使用 Web 界面将分支 dev 合并到 master 中，然后尝试使用在 dev 分支上打开的 VSCode 同步/拉取。（奇怪的是，我无法更改为 master 而不会出现此错误。）
git pull
Your configuration specifies to merge with the ref 'refs/heads/dev'
from the remote, but no such ref was fetched.'
没有找到它是有道理的 refs/heads/dev - 对我来说，删除本地文件夹并再次克隆更容易。
只需检查是否有人在远程删除了分支。
当我的磁盘已满时，我只是在执行“git pull”时遇到了这个错误。创造了一些空间，一切又开始正常工作。
当我没有使用正确的大小写时，我也遇到了同样的错误。我可以签出“集成”。 Git 告诉我执行 git pull 来更新我的分支。我这样做了，但收到了提到的错误。正确的分支名称是带有大写字母“I”的“Integration”。当我检查该分支并拉出时，它可以正常工作。
重命名本地分支
git 分支 -m 临时
显示所有分支
git 分支 -a
查看特定的远程分支
git结帐主要
删除临时分支
git 分支 -d 临时
您可以编辑主文件夹中的 ~/.gitconfig 文件。这是保存所有 --global 设置的地方。
或者，使用 git config --global --unset-all remote.origin.url 并在运行 git fetch 之后使用存储库 URL。
我面临着同样的问题，我当前的分支是 dev 并且我正在检查 MR 分支并在之后执行 git pull。我采取的一个简单的解决方法是为 MR Branch 创建了一个新文件夹，然后在那里执行 git pull 和 git clone。
所以基本上我维护了不同的文件夹来将代码推送到不同的分支。
在我的情况下，无法在新项目中获取主人。
在我把它放在命令行之后它就起作用了，
git config --global http.sslVerify false
该分支在 Github 存储库中的拉取请求已获得批准，它已合并到 dev 分支中，并且不再存在于原点。
在我的情况下，回购暂时不可用（正在维护中）。
我得到了这个确切的错误，但建议的答案（可能是区分大小写）都不是问题所在。它们可能解决了 99% 的问题，但仍然只剩下 1%。
事实证明，混合 WSL / Linux 文件共享和 Windows 基本目录是问题所在。我正在运行 WSL（Ubuntu 20.04）并且有一个从 Windows 访问/编辑的存储库，但代码在 WSL 上运行。我可能从 WSL 端做了一些 git 状态检查。
回购存在，案例是正确的，互联网工作正常，没有删除任何分支等。但我也收到错误您的配置指定与远程合并，但没有获取这样的参考。？
我的解决方法是确保所有项目都被推送/所有更改都记录下来，然后我只是删除了目录并再次从 Windows 中执行了“git clone”。然后'git checkout'工作正常。我意识到这不是一个真正的答案，但它确实有效。
我正在做 Linux 开发，其中代码库自动执行某些操作，包括“git clone”；但是，我通常会从 Windows 推送代码。我的猜测是 .git 文件夹不是跨平台兼容的（不是我有任何期望）。然而，它通常有效。它是一个错误吗？值得商榷。
git 也会偶尔尝试变得漂亮和 munge 行结尾；这是一个不同的问题（并且与宗教接壤。我是不可知论者。是的，有一个设置。）
使用 yarn 安装软件包时发生在我身上。自己的依赖项将分支 main 重命名为 master。仅更新依赖项的上游并没有解决它，我还必须清理 yarn 缓存。
项目 A 重命名了主分支（main -> master）。项目 A 是项目 B 的依赖项。项目 B 上的纱线安装 <-- 导致错误在项目 A 上推送更新的上游 项目 B 上的纱线安装 <-- 导致项目 B 上的错误纱线缓存清洁纱线安装 <-- 现在可以使用
如果另一个拉动正常，则意味着您的互联网未连接。
关注公众号
不定期副业成功案例分享
git remote prune origingit fetch --prune origin，或者在您的配置中将fetch.prune设置为true（这三个都是为了做同样的事情，尽管在一些 Git 版本中，其中一些并不完全可靠的）。git branch --set-upstream-to=origin/master master切换本地master的上游设置。 Delete-and-recreate 有一个副作用（假设您使用 DWIM 样式git checkout master创建它），还有一个额外的副作用是强制您的master匹配您的origin/master。