Git-「Refspec」とは
私は このガイド JenkinsとのGitLabの継続的統合の設定に従っています。
プロセスの一部として、respecを次のように設定する必要があります。
+refs/heads/*:refs/remotes/Origin/* +refs/merge-requests/*/head:refs/remotes/Origin/merge-requests/ *
なぜこれが必要なのかは投稿では説明されていないため、オンラインで説明を探し始め、 公式ドキュメント と関連するスタックオーバーフローの質問 このような 。
これにもかかわらず、私はまだ混乱しています-
refspecとは正確には何ですか？
そして、なぜ上記のrefspecが必要なのですか-それは何をしますか？
Refspecは、リモートからローカルリポジトリに参照をマップする方法をgitに指示します。
リストした値は+refs/heads/*:refs/remotes/Origin/* +refs/merge-requests/*/head:refs/remotes/Origin/merge-requests/*でした;それを分解しましょう。
2つのパターンがあり、それらの間にスペースがあります。これは、複数のルールを指定していることを意味します。 （pro git bookはこれを2つのrefspecと呼んでいますが、おそらく技術的にはより正しいでしょう。しかし、必要な場合は常に複数のrefspecをリストすることができるため、日常生活ではほとんど違いはありません。）
最初のパターンは+refs/heads/*:refs/remotes/Origin/*で、3つの部分があります。
+は、ターゲット参照を早送り以外の方法で移動する場合でも、エラーなしでルールを適用することを意味します。それに戻ります。
:の前（ただし、存在する場合は+の後）は「ソース」パターンです。これはrefs/heads/*です。つまり、このルールはrefs/heads（つまり、分岐）の下のすべてのリモート参照に適用されます。
:の後の部分は「宛先」パターンです。それはrefs/remotes/Origin/*です。
したがって、Originにrefs/heads/masterとして表されるmasterブランチがある場合、これはOrigin/masterとして表されるリモートブランチ参照refs/remotes/Origin/masterを作成します。ブランチ名（*）についても同様です。
+...に戻って、Originが
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への移動を許可するかどうかを決定する必要があります。デフォルトでは、これは早送りではないので許可されません（そのrefのプルを拒否したことを通知します）が、ルールは+で始まるため、それを受け入れます。
A --- B <--(master)
\
C <--(Origin/master)
（この場合、プルはマージコミットになります。）
2番目のパターンは似ていますが、merge-requests refの場合（これはサーバーのPRの実装に関連していると思われます。私はそれをよく知りません）。
Refspecsの詳細： https://git-scm.com/book/en/v2/Git-Internals-The-Refspec