Én Git-konfiguration kan betjene to helt forskellige ruter: en ekstern vært nået gennem en godkendt proxy og en intern vært nået direkte. Du behøver ikke redigere den globale standard, hver gang du skifter repository.

Git understøtter URL-specifik HTTP-konfiguration. For eksempel:

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

For et eksternt offentligt repository, hvor offentlige proxyer er tilladt, tilbyder HTTP-proxylisten kandidater til standardendepunktet. Den tomme værdi er en eksplicit tilsidesættelse for den matchende URL. Det er forskelligt fra at slette den mere specifikke nøgle, hvilket kan blotte den generiske proxy igen.

Match den URL, Git bruger

Skemaet, værtsnavnet, porten, stien og det valgfrie brugernavn deltager i de dokumenterede matchregler. Behandl ikke URL-underafsnittet som et generelt shell-jokertegnsudtryk. En snævrere stiregel kan slå en bredere værtregel.

For et skrivebeskyttet kig på den matchende proxykonfiguration:

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

Dette undersøger konfigurationsmatchning. Det er ikke en netværkstest og beviser ikke, at ruten kan nås. Tag også højde for andre konfigurationsområder og relevante miljøindstillinger.

En omdirigering er ikke et nyt konfigurationsmatch

Gits dokumentation siger, at de matchede URL'er er dem, der leveres direkte til Git-kommandoer; URL'er, der besøges på grund af en omdirigering, deltager ikke i den matchning. Hav den begrænsning i tankerne, hvis den første vært omdirigerer downloads andre steder hen.

Ruten bør også matche transporten. Et SSH-fjerndepot styres ikke af et HTTP-URL-underafsnit blot fordi den samme tjeneste tilbyder et HTTPS-websted.

Brug nogle få bevidste regler, og undersøg derefter resultatet for repræsentative URL'er. En lang ophobning af globale, repository-lokale og URL-specifikke proxyindgange er meget sværere at resonnere om end den netværksforskel, du forsøgte at udtrykke.

Relaterede artikler