您的配置指定与来自远程的 <branch name> 合并，但未获取此类引用。？
Your configuration specifies to merge with the <branch name> from the remote, but no such ref was fetched.?
我在拉取时收到此错误：
Your configuration specifies to merge with the ref
'refs/heads/feature/Sprint4/ABC-123-Branch' from the remote, but no
such ref was fetched.
任何其他分支都不会出现此错误。
此分支的特殊之处在于它是根据另一个分支的先前提交创建的。
我的配置文件如下所示：
[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 联系另一个 Git，基于 [remote "origin"] 部分下的 url 行你的配置。 Git 运行 是一个命令 (upload-pack)，除其他外，它向 您的 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 命令是一种方便的快捷方式：它 运行s git fetch 在适当的遥控器上，然后 git merge （或者，如果是这样按照 [branch ...] 部分的指示，git rebase) 使用任何需要合并（或变基）的参数。在这种情况下，您的 [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/ 远程跟踪分支以查看要合并或变基的内容。如果一次 是 这样的分支，您可能仍然有远程跟踪分支。在这种情况下，您不会收到错误消息。如果从来没有这样的分支，或者如果你有 运行 git fetch 和 --prune （它删除死的远程跟踪分支），所以你没有相应的远程跟踪分支，你会收到投诉，但它会引用 origin/feature/Sprint4/ABC-123-Branch。
无论哪种情况，我们都可以得出结论，feature/Sprint4/ABC-123-Branch 现在在名为 origin.
的远程服务器上不存在
它可能曾经存在过，并且您可能从远程跟踪分支创建了本地分支。如果是这样，您可能仍然拥有远程跟踪分支。您可能会调查谁从远程删除了分支以及为什么，或者您可能只是推送一些东西来重新创建它，或者删除您的远程跟踪分支 and/or 您的本地分支。
1好吧，它至少要承认。但除非他们专门隐藏了一些参考文献，否则该列表包含所有内容。
编辑，2020 年 7 月： 有一个新的提取协议可以避免列出 所有内容，并且只列出您的 [=112] =] 表示正在寻找。这可以帮助具有大量分支 and/or 标记的存储库。但是，如果您的 Git 对所有可能的名称感兴趣，您仍然会在此处获得所有名称。
当实际原因是我的磁盘已满时，我遇到了类似的错误。删除一些文件后，git pull 开始正常工作。
在我的例子中，我只是缺少对远程分支的初始提交，所以本地分支找不到任何可以拉取的东西，它给出了错误消息。
我做到了：
git commit -m 'first commit' // on remote branch
git pull // on local branch
如果另一个拉动正常，则表示您的互联网未连接。
对我来说，这是因为我使用 Web 界面将一个分支 dev 合并到 master，然后尝试使用 VSCode sync/pull，它在 dev 分支上打开。（很奇怪我无法更改掌握而不会出现此错误。）
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 - 对我来说，删除本地文件夹并再次克隆更容易。
对我来说，这是一个区分大小写的问题。我的本地分支是 Version_feature2 而不是 Version_Feature2。我使用正确的外壳重新检查了我的分支，然后 git pull 成功了。
检查您的远程分支是否可以拉取。
我有同样的问题，终于意识到远程分支被某人删除了。
当原始分支名称有一些大小写问题时，也会收到此错误。
例如：原始分支为team1-Team，本地分支已结帐为team1-team。那么，这个-Team中的T和-team中的t就会导致这样的错误。这发生在我的案例中。因此，通过将本地名称更改为原始分支的名称，错误得以解决。
如果 you/someone 重命名分支，也会发生这种情况。
因此，请按照以下步骤操作（如果您知道分支名称已重命名）
假设之前的分支名称为 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 pull" 时遇到了这个错误。创建了一些 space，一切又开始正常工作了。
您可以编辑主文件夹中的 ~/.gitconfig 文件。这是保存所有 --global 设置的地方。
或者，使用 git config --global --unset-all remote.origin.url 并在 运行 git fetch 之后使用存储库 url。
我一直 运行关注这个问题。就我而言，@Jerreck 关于分支名称中大小写差异的评论是导致此错误的原因。一些 Windows 工具不区分大小写。
要在 git 中关闭区分大小写，运行 此命令：
git config --global core.ignorecase true
请注意，这不仅会影响分支名称。例如，如果您在同一目录中有 "Foo.h" 和 "foo.h"（在为 Windows 构建软件时这不是一个好主意），那么我怀疑您无法关闭区分大小写。
我遇到了同样的问题，我当前的分支是 dev，我正在检查 MR 分支，然后执行 git pull。我采取的一个简单的解决方法是为 MR Branch 创建一个新文件夹，然后 git 拉到那里，然后 git 克隆。
所以基本上我维护了不同的文件夹，用于将代码推送到不同的分支。
在我的例子中，我删除了我当前分支的原始分支。所以在 .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
成功了
我刚遇到同样的错误，当时我没有使用正确的大小写。
我可以签出 'integration'。 Git 告诉我执行 git pull 来更新我的分支。我这样做了，但收到了上述错误。
正确的分支名称是 'Integration'，大写 'I'。
当我检查那个分支并拉取时，它没有问题。
您可以通过 运行 轻松 link 您的本地分支与远程分支：
git checkout <your-local-branch>
git branch --set-upstream-to=origin/<correct-remote-branch> <your-local-branch>
git pull
现在这是一个更常见的错误，因为许多项目正在将其 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
在我的例子中，我重命名了 Github 上的分支，在 return 中告诉我执行以下命令：
默认分支已重命名！
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
我在 master/main 分支中遇到了类似的问题。就我而言，我的硬盘上没有足够的可用空间 space。在释放一些 space 后，它起作用了。
我假设是因为文件 /.git 需要一些 space 来编辑它的文件。
例如文件：'refs/heads/feature/Sprint4/ABC-123-Branch'
检查是否区分大小写
在我的例子中，我的分支名称（远程）有大写字母，例如：BranchName。
一不小心，我在本地机器上创建了一个分支branchname（全部小写）并将upstream设置为相同，就出现了这个错误。
解决方法：
我删除了本地存储库，再次克隆它，然后检出到 BranchName
在我的例子中，无法在新项目中获取 master。
在我将其放入命令行后它起作用了，
git config --global http.sslVerify false
- 重命名本地分支
git branch -m temp
- 显示所有分支
git branch -a
- 查看具体的远程分支
git checkout main
- 删除临时分支
git branch -d temp
Github 仓库中分支的拉取请求已获批准，已合并到 dev 分支中，并且不再存在于 origin 上。
在我的例子中，回购暂时不可用（正在维护）。
我得到了这个确切的错误，但是 none 的建议答案（可能区分大小写）是问题所在。他们可能解决了 99% 的问题，但仍然剩下 1%。
事实证明，混合 WSL / Linux 文件共享和 Windows 基本目录是问题所在。我是 运行 WSL (Ubuntu 20.04) 并且有一个从 Windows 访问/编辑的 repo，但代码在 WSL 上是 运行。我可能已经从 WSL 端做了一些 git 状态检查。
repo 存在，大小写正确，网络正常，none 个分支被删除，等等。但是我也得到了错误 你的配置指定与来自远程，但没有获取此类引用。?
我的解决方法是确保推送所有项目/记录所有更改，然后我删除目录并从 Windows 再次执行 'git clone'。然后 'git checkout' 工作正常。我意识到这不是真正的答案，但确实有效。
我在做 Linux 开发，代码库自动执行某些操作，包括 'git clone'；但是，我通常从 Windows 进行代码推送。我的猜测是 .git 文件夹不是跨平台兼容的（并不是我有任何期望）。然而，它通常有效。这是一个错误吗？值得商榷。
git 偶尔也会过分努力地表现得很好，并且把行结尾搞得乱七八糟；那是一个不同的问题（并且与宗教接壤。我是不可知论者。是的，有一个设置。）
我发现从默认 master 分支已重命名为 main 的存储库中提取更新时，经常会出现此错误。
在 2020 年将 master 分支重命名为 main 分支的趋势之后遇到了很多。
因此，如果您之前使用默认 master 分支克隆了一个 repo，并且该分支已重命名为 main，一种修复方法是简单地将您的上游从 master 指向 main :
git branch --set-upstream-to=origin/main master
如果该命令成功，您应该会看到如下消息：
Branch 'master' set up to track remote branch 'main' from 'origin'.
然后您可以使用 git branch -m master main
将本地分支从 master 重命名为 main（以与远程分支名称保持一致）
使用 yarn 安装软件包时发生在我身上。自己的依赖项将分支 main 重命名为 master。仅在依赖项上更新上游并没有修复它，我还必须清理 yarn 缓存。
项目 A 重命名为主要分支 (main -> master)。项目 A 是项目 B 的依赖项。
yarn install 项目 B <-- 导致错误
项目 A
yarn install 项目 B <-- 导致错误
yarn cache clean
yarn install 项目 B <-- 现在有效
我在拉取时收到此错误：
Your configuration specifies to merge with the ref 'refs/heads/feature/Sprint4/ABC-123-Branch' from the remote, but no such ref was fetched.
任何其他分支都不会出现此错误。
此分支的特殊之处在于它是根据另一个分支的先前提交创建的。
我的配置文件如下所示：
[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 联系另一个 Git，基于 [remote "origin"] 部分下的 url 行你的配置。 Git 运行 是一个命令 (upload-pack)，除其他外，它向 您的 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 命令是一种方便的快捷方式：它 运行s git fetch 在适当的遥控器上，然后 git merge （或者，如果是这样按照 [branch ...] 部分的指示，git rebase) 使用任何需要合并（或变基）的参数。在这种情况下，您的 [branch "feature/Sprint4/ABC-123-Branch"] 部分表示从 origin 获取，然后与在名称 refs/heads/feature/Sprint4/ABC-123-Branch.
由于在该名称下找不到任何内容，git pull 抱怨并停止。
如果你 运行 这作为两个单独的步骤，git fetch 然后 git merge （或 git rebase），你的 Git 会查看你的缓存remotes/origin/ 远程跟踪分支以查看要合并或变基的内容。如果一次 是 这样的分支，您可能仍然有远程跟踪分支。在这种情况下，您不会收到错误消息。如果从来没有这样的分支，或者如果你有 运行 git fetch 和 --prune （它删除死的远程跟踪分支），所以你没有相应的远程跟踪分支，你会收到投诉，但它会引用 origin/feature/Sprint4/ABC-123-Branch。
无论哪种情况，我们都可以得出结论，feature/Sprint4/ABC-123-Branch 现在在名为 origin.
它可能曾经存在过，并且您可能从远程跟踪分支创建了本地分支。如果是这样，您可能仍然拥有远程跟踪分支。您可能会调查谁从远程删除了分支以及为什么，或者您可能只是推送一些东西来重新创建它，或者删除您的远程跟踪分支 and/or 您的本地分支。
1好吧，它至少要承认。但除非他们专门隐藏了一些参考文献，否则该列表包含所有内容。
编辑，2020 年 7 月： 有一个新的提取协议可以避免列出 所有内容，并且只列出您的 [=112] =] 表示正在寻找。这可以帮助具有大量分支 and/or 标记的存储库。但是，如果您的 Git 对所有可能的名称感兴趣，您仍然会在此处获得所有名称。
当实际原因是我的磁盘已满时，我遇到了类似的错误。删除一些文件后，git pull 开始正常工作。
在我的例子中，我只是缺少对远程分支的初始提交，所以本地分支找不到任何可以拉取的东西，它给出了错误消息。
我做到了：
git commit -m 'first commit' // on remote branch
git pull // on local branch
如果另一个拉动正常，则表示您的互联网未连接。
对我来说，这是因为我使用 Web 界面将一个分支 dev 合并到 master，然后尝试使用 VSCode sync/pull，它在 dev 分支上打开。（很奇怪我无法更改掌握而不会出现此错误。）
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 - 对我来说，删除本地文件夹并再次克隆更容易。
对我来说，这是一个区分大小写的问题。我的本地分支是 Version_feature2 而不是 Version_Feature2。我使用正确的外壳重新检查了我的分支，然后 git pull 成功了。
检查您的远程分支是否可以拉取。 我有同样的问题，终于意识到远程分支被某人删除了。
当原始分支名称有一些大小写问题时，也会收到此错误。
例如：原始分支为team1-Team，本地分支已结帐为team1-team。那么，这个-Team中的T和-team中的t就会导致这样的错误。这发生在我的案例中。因此，通过将本地名称更改为原始分支的名称，错误得以解决。
如果 you/someone 重命名分支，也会发生这种情况。
因此，请按照以下步骤操作（如果您知道分支名称已重命名）
假设之前的分支名称为 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 pull" 时遇到了这个错误。创建了一些 space，一切又开始正常工作了。
您可以编辑主文件夹中的 ~/.gitconfig 文件。这是保存所有 --global 设置的地方。
或者，使用 git config --global --unset-all remote.origin.url 并在 运行 git fetch 之后使用存储库 url。
我一直 运行关注这个问题。就我而言，@Jerreck 关于分支名称中大小写差异的评论是导致此错误的原因。一些 Windows 工具不区分大小写。
要在 git 中关闭区分大小写，运行 此命令：
git config --global core.ignorecase true
请注意，这不仅会影响分支名称。例如，如果您在同一目录中有 "Foo.h" 和 "foo.h"（在为 Windows 构建软件时这不是一个好主意），那么我怀疑您无法关闭区分大小写。
我遇到了同样的问题，我当前的分支是 dev，我正在检查 MR 分支，然后执行 git pull。我采取的一个简单的解决方法是为 MR Branch 创建一个新文件夹，然后 git 拉到那里，然后 git 克隆。
所以基本上我维护了不同的文件夹，用于将代码推送到不同的分支。
在我的例子中，我删除了我当前分支的原始分支。所以在 .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
成功了
我刚遇到同样的错误，当时我没有使用正确的大小写。
我可以签出 'integration'。 Git 告诉我执行 git pull 来更新我的分支。我这样做了，但收到了上述错误。
正确的分支名称是 'Integration'，大写 'I'。
当我检查那个分支并拉取时，它没有问题。
您可以通过 运行 轻松 link 您的本地分支与远程分支：
git checkout <your-local-branch>
git branch --set-upstream-to=origin/<correct-remote-branch> <your-local-branch>
git pull
现在这是一个更常见的错误，因为许多项目正在将其 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
在我的例子中，我重命名了 Github 上的分支，在 return 中告诉我执行以下命令：
默认分支已重命名！
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
我在 master/main 分支中遇到了类似的问题。就我而言，我的硬盘上没有足够的可用空间 space。在释放一些 space 后，它起作用了。
我假设是因为文件 /.git 需要一些 space 来编辑它的文件。 例如文件：'refs/heads/feature/Sprint4/ABC-123-Branch'
检查是否区分大小写
在我的例子中，我的分支名称（远程）有大写字母，例如：BranchName。
一不小心，我在本地机器上创建了一个分支branchname（全部小写）并将upstream设置为相同，就出现了这个错误。
解决方法：
我删除了本地存储库，再次克隆它，然后检出到 BranchName
在我的例子中，无法在新项目中获取 master。
在我将其放入命令行后它起作用了，
git config --global http.sslVerify false
- 重命名本地分支
git branch -m temp
- 显示所有分支
git branch -a
- 查看具体的远程分支
git checkout main
- 删除临时分支
git branch -d temp
Github 仓库中分支的拉取请求已获批准，已合并到 dev 分支中，并且不再存在于 origin 上。
在我的例子中，回购暂时不可用（正在维护）。
我得到了这个确切的错误，但是 none 的建议答案（可能区分大小写）是问题所在。他们可能解决了 99% 的问题，但仍然剩下 1%。
事实证明，混合 WSL / Linux 文件共享和 Windows 基本目录是问题所在。我是 运行 WSL (Ubuntu 20.04) 并且有一个从 Windows 访问/编辑的 repo，但代码在 WSL 上是 运行。我可能已经从 WSL 端做了一些 git 状态检查。
repo 存在，大小写正确，网络正常，none 个分支被删除，等等。但是我也得到了错误 你的配置指定与来自远程，但没有获取此类引用。?
我的解决方法是确保推送所有项目/记录所有更改，然后我删除目录并从 Windows 再次执行 'git clone'。然后 'git checkout' 工作正常。我意识到这不是真正的答案，但确实有效。
我在做 Linux 开发，代码库自动执行某些操作，包括 'git clone'；但是，我通常从 Windows 进行代码推送。我的猜测是 .git 文件夹不是跨平台兼容的（并不是我有任何期望）。然而，它通常有效。这是一个错误吗？值得商榷。
git 偶尔也会过分努力地表现得很好，并且把行结尾搞得乱七八糟；那是一个不同的问题（并且与宗教接壤。我是不可知论者。是的，有一个设置。）
我发现从默认 master 分支已重命名为 main 的存储库中提取更新时，经常会出现此错误。
在 2020 年将 master 分支重命名为 main 分支的趋势之后遇到了很多。
因此，如果您之前使用默认 master 分支克隆了一个 repo，并且该分支已重命名为 main，一种修复方法是简单地将您的上游从 master 指向 main :
git branch --set-upstream-to=origin/main master
如果该命令成功，您应该会看到如下消息：
Branch 'master' set up to track remote branch 'main' from 'origin'.
然后您可以使用 git branch -m master main
master 重命名为 main（以与远程分支名称保持一致）
使用 yarn 安装软件包时发生在我身上。自己的依赖项将分支 main 重命名为 master。仅在依赖项上更新上游并没有修复它，我还必须清理 yarn 缓存。
项目 A 重命名为主要分支 (
main->master)。项目 A 是项目 B 的依赖项。yarn install项目 B <-- 导致错误yarn install项目 B <-- 导致错误yarn cache cleanyarn install项目 B <-- 现在有效