我得到这个错误拉:
您的配置指定与ref合并
'refs/heads/feature/Sprint4/ABC-123-Branch'，但没有
这样的裁判是拿来的。
这个错误不会出现在任何其他分支上。这个分支的特殊之处在于，它是从另一个分支的上一次提交中创建的。
我的配置文件如下:
[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
我发现当从默认主分支重命名为主分支的回购中提取更新时，经常发生这种错误。
在2020年将主分支重命名为主分支的趋势之后，遇到了很多这种情况。
因此，如果你之前用默认的主分支克隆了一个repo，并且这个分支已经重命名为main，一种修复方法是简单地将你的上游从master指向main:
Git分支——set-upstream-to=origin/main master
如果该命令成功，您应该看到如下消息:
分支'master'设置为从'origin'跟踪远程分支'main'。
然后，你可以使用git branch -m master main将本地分支从master重命名为main(以保持与远程分支名称一致)
我得到了这个确切的错误，但没有一个建议的答案(可能是大小写敏感)是问题。它们可能适用于99%的问题，但还剩下1%。
事实证明，混合使用WSL / Linux文件共享和Windows基目录是问题所在。我正在运行WSL (Ubuntu 20.04)，并有一个从Windows访问/编辑的repo，但代码是在WSL上运行的。我可能已经从WSL方面做了一些git状态检查。
回购是存在的，案例是正确的，互联网工作正常，没有一个分支被删除，等等。然而，我也得到了错误，你的配置指定从远程合并，但没有这样的参考。
我的修复是，是确保所有的项目都被推送/所有的更改都被记录，然后我只是删除了目录，并再次从Windows中做了一个“git克隆”。然后'git checkout'就可以正常工作了。我知道这不是一个真正的答案，但它确实起作用了。
我在做Linux开发，代码库可以自动执行某些操作，包括“git克隆”;然而，我通常在Windows上进行代码推送。我的猜测是。git文件夹不是跨平台兼容的(并不是我有任何期望)。然而，它通常是有效的。是bug吗?争议。
Git偶尔也会试图做一个漂亮的和蒙面的行尾;这是一个不同的问题(与宗教相近)。我是不可知论者。是的，有一个设定。)
我刚刚经历了“no such ref was fetch”的问题，以上建议都没有帮助。我解决这个问题的方法是改变我的本地配置
remote.origin.fetch=+refs/heads/master:refs/remotes/origin/master
to
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*
我不知道为什么会起作用，但确实起了作用。经过这个改变，我可以拉，得到我所期望的。
如果我把它改回来，我在试图拉的时候再次得到“no such ref was fetch”。所以这绝对是修复(不是蹩脚的互联网，或情况差异，或全驱动器，或删除远程分支，或默认分支不命名为“master”等)。
