En enda Git-konfiguration kan betjäna två helt olika rutter: en extern värd som nås via en godkänd proxy och en intern värd som nås direkt. Du behöver inte redigera det globala standardvärdet varje gång du byter repository.

Git stöder URL-specifik HTTP-konfiguration. Till exempel:

[http]
    proxy = http://proxy.example:8080
[http "https://git.office.example/"]
    proxy =

För ett externt offentligt repository där offentliga proxyserver är tillåtna erbjuder HTTP-proxylistan kandidater för standardändpunkten. Det tomma värdet är en uttrycklig åsidosättning för den matchande URL:en. Det skiljer sig från att ta bort den mer specifika nyckeln, vilket kan blotta den generiska proxyn igen.

Matcha URL:en som Git använder

Schemat, värdnamnet, porten, sökvägen och det valfria användarnamnet deltar i de dokumenterade matchningsreglerna. Behandla inte URL-undersektionen som ett allmänt shell-jokerteckenuttryck. En snävare sökvägsregel kan slå en bredare värdregel.

För en skrivskyddad titt på den matchande proxykonfigurationen:

git config --get-urlmatch http.proxy https://git.office.example/team/project.git

Detta granskar konfigurationsmatchningen. Det är inte ett nätverkstest och bevisar inte att rutten är nåbar. Tänk också på andra konfigurationsomfång och relevanta miljöinställningar.

En omdirigering är inte en ny konfigurationsmatchning

Gits dokumentation säger att de matchade URL:erna är de som ges direkt till Git-kommandon; URL:er som besöks på grund av en omdirigering deltar inte i den matchningen. Ha den begränsningen i åtanke om den första värden omdirigerar nedladdningar någon annanstans.

Rutten bör också matcha transporten. En SSH-fjärr styrs inte av en HTTP-URL-undersektion bara för att samma tjänst erbjuder en HTTPS-webbplats.

Använd några få avsiktliga regler och granska sedan resultatet för representativa URL:er. En lång ansamling av globala, repositorielokala och URL-specifika proxy poster är mycket svårare att resonera kring än den nätverksskillnad du försökte uttrycka.

Relaterade artiklar