Un refspec indique à git comment la carte des références à partir d'une télécommande pour le local des pensions.
La valeur que vous avez indiquée a été +refs/heads/*:refs/remotes/origin/* +refs/merge-requests/*/head:refs/remotes/origin/merge-requests/*; donc, nous allons casser vers le bas.
Vous avez deux modèles avec un espace entre eux; cela signifie simplement que vous êtes en donnant de multiples règles. (Le pro git livre se réfère à ce que les deux refspecs; ce qui est probablement techniquement correct. Toutefois, vous serez toujours avoir la possibilité de lister plusieurs refspecs si vous en avez besoin, donc, dans la vie de tous les jours il a probablement fait peu de différence.)
Le premier motif, alors, est - +refs/heads/*:refs/remotes/origin/* qui a trois parties:
L' + moyens d'appliquer la règle sans échec, même si cela entraîne un déplacement d'une cible ref dans un non-fast-forward manière. Je vais revenir.
La partie avant de l' : (mais après l' + si il y en a un) est la "source" de modèle. C'est refs/heads/*, ce qui signifie que cette règle s'applique à toute distance de référence en vertu de l' refs/heads (ce qui signifie, les branches).
La partie après le : est la "destination" de modèle. C'est refs/remotes/origin/*.
Donc, si l'origine a une succursale master, représentée comme refs/heads/master, cela permettra de créer une branche distante de référence origin/master représentés en refs/remotes/origin/master. Et ainsi de suite pour tout nom de la branche (*).
Donc, retour à que +... supposons que l'origine a
A --- B <--(master)
Vous chercher et, en l'appliquant refspec vous obtenez
A --- B <--(origin/master)
(Si vous avez appliqué typique règles de suivi et a fait un pull vous avez également master a souligné B.)
A --- B <--(origin/master)(master)
Maintenant, certaines choses se produire sur la télécommande. Quelqu'un peut-être effectué reset qui a effacé B, puis commis C, puis a forcé à pousser. Si la télécommande dit
A --- C <--(master)
Lorsque vous chercher, vous obtenez
A --- B
\
C
et git doivent décider d'autoriser le déplacement de l' origin/master de B de C. Par défaut, il ne permettrait pas cela parce que ce n'est pas un fast-forward (il vous dira qu'il a rejeté la tirer pour qu'ref), mais parce que la règle commence par + il va l'accepter.
A --- B <--(master)
\
C <--(origin/master)
(Un pull dans ce cas aboutir à une fusion s'engager.)
La deuxième tendance est similaire, mais pour l' merge-requests refs (qui je suppose est lié à votre serveur de mise en œuvre de la PR; je ne suis pas familier avec elle).
Plus sur refspecs: https://git-scm.com/book/en/v2/Git-Internals-The-Refspec
