refspec告诉git如何将引用从远程映射到本地仓库。
您列出的值是
+refs/headshead:refs/remotes/origin/merge-requests/*; 所以让我们分解一下。
您有两个模式，它们之间有一个间隔；这只是意味着您要给出多个规则。（专业版git书将其称为两个refspecs；从技术上讲，这可能更正确。但是，您几乎总是可以列出多个refspecs，因此在日常生活中，这可能几乎没有什么区别。）
那么，第一种模式
+refs/heads/*:refs/remotes/origin/*包括三个部分：
- 该
+
方法适用无故障的规则，即使这样做会在非快进方式移动的目标参考。我会回到那。 - 在
:
（但+
如果有的话之后）之前的部分是“源”模式。即refs/heads/*
，表示此规则适用于refs/heads
（含义，分支）下的任何远程引用。 - 后面的部分
:
是“目标”模式。那是refs/remotes/origin/*
。
因此，如果原点有一个分支
master表示为
refs/heads/master，这将创建一个远程分支引用
origin/master表示为
refs/remotes/origin/master。对于任何分支名称（
*）依此类推。
回到那个
+…假设起源
A --- B <--(master)
您获取并应用该refspec即可
A --- B <--(origin/master)
（如果您应用了典型的跟踪规则并且做了，
pull您也已经
master指出了
B。）
A --- B <--(origin/master)(master)
现在，某些事情发生在遥控器上。也许有人做了一个
reset删除
B，然后提交
C，然后强行推动的操作。所以遥控器说
A --- C <--(master)
当您获取时，您会得到
A --- B C
和git必须决定是否允许
origin/master从
B到的移动
C。默认情况下，这是不允许的，因为它不是一个快进（它会告诉您它拒绝了该引用的请求），但是因为规则以
+它开头而将接受它。
A --- B <--(master) C <--(origin/master)
（在这种情况下，拉动将导致合并提交。）
第二种模式是相似的，但是对于
merge-requests引用（我认为与您的服务器对PR的实现有关；我不熟悉）。
有关refspec的更多信息：https : //git-scm.com/book/en/v2/Git-Internals-The-Refspec
