Git - Qu'est-ce que "Refspec"?
Je suis ce guide pour configurer l’intégration continue de GitLab avec Jenkins.
Dans le cadre du processus, il est nécessaire de définir le respec comme suit
+refs/heads/*:refs/remotes/Origin/* +refs/merge-requests/*/head:refs/remotes/Origin/merge-requests/ *
La raison pour laquelle cela est nécessaire n’est pas expliquée dans le post, j’ai donc commencé à chercher une explication en ligne et j’ai jeté un œil à la documentation officielle ainsi qu’à certaines questions connexes relatives au dépassement de pile comme celle-ci .
Malgré cela, je suis toujours confus -
En quoi consiste exactement refspec?
Et pourquoi la référence ci-dessus est-elle nécessaire - que fait-elle?
Un refspec indique à git comment mapper les références d'une télécommande au référentiel local.
La valeur que vous avez indiquée était +refs/heads/*:refs/remotes/Origin/* +refs/merge-requests/*/head:refs/remotes/Origin/merge-requests/*; alors décomposons cela.
Vous avez deux modèles avec un espace entre eux; cela signifie simplement que vous donnez plusieurs règles. (Le livre professionnel appelle cela deux référentiels, ce qui est probablement plus correct techniquement. Cependant, vous avez toujours la possibilité de répertorier plusieurs référentiels si vous en avez besoin, donc dans la vie quotidienne, cela ne fera probablement que peu de différence.)
Le premier motif est donc +refs/heads/*:refs/remotes/Origin/* qui comporte trois parties:
Le + signifie appliquer la règle sans échec, même si cela déplacerait une référence cible de manière non rapide. J'y reviendrai.
La partie avant le : (mais après le + s'il y en a un) est le motif "source". C'est refs/heads/*, signifiant que cette règle s’applique à toute référence distante sous refs/heads (signification, branches).
La partie après le : est le motif "destination". C'est refs/remotes/Origin/*.
Donc, si l’origine a une branche master, représentée par refs/heads/master, cela créera une référence de branche distante Origin/master représenté comme refs/remotes/Origin/master. Et ainsi de suite pour tout nom de branche (*).
Revenons donc à ça +... supposons que l'origine a
A --- B <--(master)
Vous récupérez et, en appliquant cette référence, vous obtenez
A --- B <--(Origin/master)
(Si vous avez appliqué des règles de suivi typiques et effectué un pull, vous avez également master pointé sur B.)
A --- B <--(Origin/master)(master)
Maintenant, certaines choses se passent sur la télécommande. Quelqu'un a peut-être fait une reset qui a effacé B, puis a validé C, puis a forcé un Push. Alors la télécommande dit
A --- C <--(master)
Quand vous allez chercher, vous obtenez
A --- B
\
C
et git doit décider d'autoriser ou non le déplacement de Origin/master de B à C. Par défaut, cela ne le permettrait pas car ce n'est pas un fast-forward (il vous dirait qu'il a rejeté l'extraction de cette référence), mais parce que la règle commence par + il l'acceptera.
A --- B <--(master)
\
C <--(Origin/master)
(Un pull aboutira dans ce cas à un commit de fusion.)
Le second motif est similaire, mais pour merge-requests refs (qui, je suppose, est lié à la mise en œuvre des PR par votre serveur; je ne le connais pas bien).
En savoir plus sur refspecs: https://git-scm.com/book/en/v2/Git-Internals-The-Refspec