Geben Sie Git unterschiedliche Proxy-Regeln für unterschiedliche Hosts

Gits URL-spezifische HTTP-Konfiguration kann einen internen Dienst direkt halten, während an anderer Stelle ein Proxy erhalten bleibt. Prüfen Sie das Übereinstimmungsergebnis für die genaue URL.

Eine Git-Konfiguration kann zwei ganz unterschiedliche Wege bedienen: einen externen Host, der über einen genehmigten Proxy erreicht wird, und einen internen Host, der direkt erreicht wird. Sie müssen nicht jedes Mal den globalen Standard ändern, wenn Sie das Repository wechseln.

Git unterstützt URL-spezifische HTTP-Konfiguration. Zum Beispiel:

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

Für ein externes öffentliches Repository, in dem öffentliche Proxys zulässig sind, bietet die HTTP-Proxy-Liste Kandidaten für den Standardendpunkt. Der leere Wert ist eine ausdrückliche Überschreibung für die passende URL. Er unterscheidet sich vom Löschen jenes spezifischeren Schlüssels, was den allgemeinen Proxy wieder freilegen kann.

Passen Sie die von Git verwendete URL ab

Schema, Hostname, Port, Pfad und optionaler Benutzername nehmen an den dokumentierten Abgleichregeln teil. Behandeln Sie den URL-Unterabschnitt nicht als allgemeinen Shell-Wildcard-Ausdruck. Eine engere Pfadregel kann eine breitere Hostregel schlagen.

Für einen schreibgeschützten Blick auf die passende Proxy-Konfiguration:

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

Dies prüft den Konfigurationsabgleich. Es ist kein Netzwerktest und belegt nicht, dass die Route erreichbar ist. Berücksichtigen Sie auch andere Konfigurationsbereiche und relevante Umgebungseinstellungen.

Eine Weiterleitung ist kein neuer Konfigurationsabgleich

Die Git-Dokumentation besagt, dass die abgeglichenen URLs jene sind, die Git-Befehlen direkt übergeben werden; URLs, die wegen einer Weiterleitung besucht werden, nehmen an diesem Abgleich nicht teil. Beachten Sie diese Einschränkung, wenn der erste Host Downloads woandershin weiterleitet.

Die Route sollte auch zum Transport passen. Ein SSH-Remote wird nicht von einem HTTP-URL-Unterabschnitt geregelt, nur weil derselbe Dienst eine HTTPS-Website anbietet.

Verwenden Sie wenige bewusste Regeln und prüfen Sie dann das Ergebnis für repräsentative URLs. Eine lange Anhäufung globaler, repository-lokaler und URL-spezifischer Proxy-Einträge ist viel schwerer zu durchschauen als die Netzwerkunterscheidung, die Sie ausdrücken wollten.

Ähnliche Artikel