refspec告诉git如何将引用从远程映射到本地仓库。

您列出的值是+refs/heads/*:refs/remotes/origin/* +refs/merge- requests/*/head:refs/remotes/origin/merge-requests/*; 所以让我们分解一下。

您有两个模式，它们之间有一个间隔；这只是意味着您要给出多个规则。（专业版git书将其称为两个refspecs；从技术上讲，这可能更正确。但是，您几乎总是可以列出多个refspecs，因此在日常生活中，这可能几乎没有什么区别。）

那么，第一种模式+refs/heads/*:refs/remotes/origin/*包括三个部分：

1. 该+方法适用无故障的规则，即使这样做会在非快进方式移动的目标参考。我会回到那。
2. 在:（但+如果有的话之后）之前的部分是“源”模式。即refs/heads/*，表示此规则适用于refs/heads（含义，分支）下的任何远程引用。
3. 后面的部分:是“目标”模式。那是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