Git - 什么是“参考规范”

Git - What is "Refspec"

提问by Mark Adelsberger

I've been following this guideon configuring GitLab continuous integration with Jenkins.

我一直在遵循有关配置 GitLab 与 Jenkins 持续集成的指南。

As part of the process, it is necessary to set the respec as follows

作为过程的一部分，有必要设置 respec 如下

+refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*

+refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*

Why this is necessary is not explained in the post, so I began looking online for an explanation and looked at the official documentationas well as some related stack overflow questions like this one.

为什么有必要在帖子中没有解释，所以我开始在网上寻找解释并查看了官方文档以及一些相关的堆栈溢出问题，例如this one。

In spite of this, I'm still confused -

尽管如此，我还是很困惑——

What exactly is refspec?

refspec 究竟是什么？

And why is the above refspec necessary - what does it do?

为什么上述 refspec 是必要的 - 它有什么作用？

回答by Mark Adelsberger

A refspec tells git how to map references from a remote to the local repo.

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

The value you listed was +refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*; so let's break that down.

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

You have two patterns with a space between them; this just means you're giving multiple rules. (The pro git book refers to this as two refspecs; which is probably technically more correct. However, you just about always have the ability to list multiple refspecs if you need to, so in day to day life it likely makes little difference.)

你有两个图案，它们之间有一个空格；这只是意味着你给出了多个规则。（pro git book 将此称为两个 refspecs；这在技术上可能更正确。但是，如果需要，您几乎总是能够列出多个 refspecs，因此在日常生活中它可能没什么区别。）

The first pattern, then, is +refs/heads/*:refs/remotes/origin/*which has three parts:

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

1. The +means to apply the rule without failure even if doing so would move a target ref in a non-fast-forward manner. I'll come back to that.
2. The part before the :(but after the +if there is one) is the "source" pattern. That's refs/heads/*, meaning this rule applies to any remote reference under refs/heads(meaning, branches).
3. The part after the :is the "destination" pattern. That's refs/remotes/origin/*.

1. 该+方法适用无故障的规则，即使这样做会在非快进方式移动的目标参考。我会回到那个。
2. 之前:（但+如果有的话）之前的部分是“源”模式。那就是refs/heads/*，这意味着此规则适用于refs/heads（含义，分支）下的任何远程引用。
3. 之后的部分:是“目的地”模式。那是refs/remotes/origin/*。

So if the origin has a branch master, represented as refs/heads/master, this will create a remote branch reference origin/masterrepresented as refs/remotes/origin/master. And so on for any branch name (*).

因此，如果源有一个分支master，表示为refs/heads/master，这将创建一个origin/master表示为的远程分支引用refs/remotes/origin/master。对任何分支名称 ( *)依此类推。

So back to that +... suppose the origin has

所以回到那个+......假设起源有

A --- B <--(master)

You fetch and, applying that refspec you get

你获取并应用你得到的 refspec

A --- B <--(origin/master)

(If you applied typical tracking rules and did a pullyou also have masterpointed at B.)

（如果您应用了典型的跟踪规则并执行了 a，pull那么您还master指出了B。）

A --- B <--(origin/master)(master)

Now some things happen on the remote. Someone maybe did a resetthat erased B, then committed C, then forced a push. So the remote says

现在遥控器上发生了一些事情。有人可能做了一个reset擦除B，然后提交C，然后强行推动。所以遥控器说

A --- C <--(master)

When you fetch, you get

当你获取时，你得到

A --- B
 \
  C

and git must decide whether to allow the move of origin/masterfrom Bto C. By default it wouldn't allow this because it's not a fast-forward (it would tell you it rejected the pull for that ref), but because the rule starts with +it will accept it.

并且 git 必须决定是否允许移动origin/masterfromB到C。默认情况下它不允许这样做，因为它不是快进（它会告诉您它拒绝了该引用的拉取），但是因为规则以+它开头，它将接受它。

A --- B <--(master)
 \
  C <--(origin/master)

(A pull will in this case result in a merge commit.)

（在这种情况下，拉取将导致合并提交。）

The second pattern is similar, but for merge-requestsrefs (which I assume is related to your server's implementation of PR's; I'm not familiar with it).

第二种模式是类似的，但对于merge-requestsrefs（我认为这与您的服务器对 PR 的实现有关；我不熟悉它）。

More about refspecs: https://git-scm.com/book/en/v2/Git-Internals-The-Refspec

更多关于 refspecs：https: //git-scm.com/book/en/v2/Git-Internals-The-Refspec