Én Git-konfigurasjon kan betjene to helt forskjellige ruter: en ekstern vert nådd gjennom en godkjent proxy og en intern vert nådd direkte. Du trenger ikke redigere den globale standarden hver gang du bytter repository.

Git støtter URL-spesifikk HTTP-konfigurasjon. For eksempel:

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

For et eksternt offentlig repository der offentlige proxyer er tillatt, tilbyr HTTP-proxylisten kandidater for standardendepunktet. Den tomme verdien er en eksplisitt overstyring for den samsvarende URL-en. Det er forskjellig fra å slette den mer spesifikke nøkkelen, som kan blottstille den generiske proxyen igjen.

Match URL-en Git bruker

Skjemaet, vertsnavnet, porten, banen og det valgfrie brukernavnet deltar i de dokumenterte matchreglene. Ikke behandle URL-underveisningen som et generelt shell-jokertegnuttrykk. En snevrere baneregel kan slå en bredere vertsregel.

For et skrivebeskyttet innblikk i den samsvarende proxykonfigurasjonen:

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

Dette undersøker konfigurasjonsmatching. Det er ikke en nettverkstest og beviser ikke at ruten er nåbar. Ta også hensyn til andre konfigurasjonsområder og relevante miljøinnstillinger.

En omdirigering er ikke en ny konfigurasjonsmatch

Gits dokumentasjon sier at de samsvarende URL-ene er de som gis direkte til Git-kommandoer; URL-er som besøkes på grunn av en omdirigering, deltar ikke i den matchingen. Ha den begrensningen i tankene hvis den første verten omdirigerer nedlastinger et annet sted.

Ruten bør også samsvare med transporten. En SSH-fjernlagring styres ikke av en HTTP-URL-underveisning bare fordi den samme tjenesten tilbyr et HTTPS-nettsted.

Bruk noen få bevisste regler, og undersøk deretter resultatet for representative URL-er. En lang opphopning av globale, repositorielokale og URL-spesifikke proxyoppføringer er mye vanskeligere å resonnere om enn nettverksforskjellen du prøvde å uttrykke.

Relaterte artikler