我得到这个错误拉:

您的配置指定与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

当前回答

我得到了这个确切的错误,但没有一个建议的答案(可能是大小写敏感)是问题。它们可能适用于99%的问题,但还剩下1%。

事实证明,混合使用WSL / Linux文件共享和Windows基目录是问题所在。我正在运行WSL (Ubuntu 20.04),并有一个从Windows访问/编辑的repo,但代码是在WSL上运行的。我可能已经从WSL方面做了一些git状态检查。

回购是存在的,案例是正确的,互联网工作正常,没有一个分支被删除,等等。然而,我也得到了错误,你的配置指定从远程合并,但没有这样的参考。

我的修复是,是确保所有的项目都被推送/所有的更改都被记录,然后我只是删除了目录,并再次从Windows中做了一个“git克隆”。然后'git checkout'就可以正常工作了。我知道这不是一个真正的答案,但它确实起作用了。

我在做Linux开发,代码库可以自动执行某些操作,包括“git克隆”;然而,我通常在Windows上进行代码推送。我的猜测是。git文件夹不是跨平台兼容的(并不是我有任何期望)。然而,它通常是有效的。是bug吗?争议。

Git偶尔也会试图做一个漂亮的和蒙面的行尾;这是一个不同的问题(与宗教相近)。我是不可知论者。是的,有一个设定。)

其他回答

如果再拉一次还能用,说明你的网络没有连接。

分支在Github回购中的拉请求被批准了,它被合并到开发分支中,不再存在。

重命名本地分支

Git分支-m temp

显示所有分支

Git分支-a

签出特定的远程分支

Git checkout main

删除临时分支

Git分支-d temp

这意味着什么

您的上游(您调用origin的远程)不再拥有,或者可能从未拥有(仅从此信息无法判断)名为feature/Sprint4/ABC-123-Branch的分支。有一个特别常见的原因:有人(可能不是您,或者您应该记得)删除了另一个Git存储库中的分支。

该怎么做

这取决于你想要什么。请参阅下面的讨论部分。您可以:

在远程上创建或重新创建分支,或者 删除本地分支,或者 任何你能想到的。

讨论

你必须运行git pull(如果你运行git merge,你会得到一个不同的错误消息或者根本没有错误消息)。

当你运行git fetch时,你的git会根据你配置的[remote "origin"]部分下的url行联系另一个git。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/ entries列出了远程存在的所有分支,1以及相应的提交id(对于refs/tags/ entries, id可能指向标记对象而不是提交)。

Git获取每个分支名称,并根据同一个远程段中的获取行更改它。例如,在这种情况下,Git将refs/heads/master替换为refs/remotes/origin/master。Git对遇到的每个分支名称都这样做。

它还在特殊文件FETCH_HEAD中记录原始名称(如果您查看自己的.git目录,可以看到这个文件)。该文件保存获取的名称和id。

git pull命令意味着一个方便的捷径:它在适当的远程上运行git fetch,然后git merge(或者,如果有指示,git rebase)与任何需要合并(或rebase)的参数,由[分支…)部分。在这种情况下,你的[branch "feature/Sprint4/ABC-123-Branch"]部分表示从原点获取,然后与在refs/heads/feature/Sprint4/ABC-123-Branch名称下找到的任何ID合并。

因为在这个名字下没有发现任何东西,git抱怨并停止。

If you run this as two separate steps, git fetch and then git merge (or git rebase), your Git would look at your cached remotes/origin/ remote-tracking branches to see what to merge with or rebase onto. If there was such a branch at one time, you may still have the remote-tracking branch. In this case, you would not get an error message. If there was never such a branch, or if you have run git fetch with --prune (which removes dead remote-tracking branches), so that you have no corresponding remote-tracking branch, you would get a complaint, but it would refer to origin/feature/Sprint4/ABC-123-Branch instead.

无论哪种情况,我们都可以得出结论,feature/Sprint4/ABC-123-Branch现在在命名为origin的远程服务器上不存在。

它可能曾经存在过,并且您可能从远程跟踪分支创建了本地分支。如果是这样,您可能仍然拥有远程跟踪分支。您可能会调查是谁从远程中删除了分支,以及为什么,或者您可能只是推送一些东西来重新创建它,或者删除远程跟踪分支和/或本地分支。


好吧,至少它会承认这一点。但除非他们特别隐藏了一些裁判,这个列表包括了一切。

编辑,2020年7月:有一个新的获取协议,可以避免列出所有东西,只列出你的Git说它正在寻找的名称。这对于具有大量分支和/或标记的存储库很有帮助。但是,如果Git对所有可能的名称都感兴趣,那么仍然可以在这里获得所有名称。

我在远程中被合并和删除的分支中。在一家存在的分行结账,然后取款,这对我有帮助。