Einen Proxy für ein einzelnes Git-Repository verwenden

Sie brauchen keinen globalen Git-Proxy, nur weil ein Projekt eine andere Verbindung benötigt. Ein vorhandener Checkout hat eine eigene lokale Konfiguration, sodass die Änderung bei diesem Repository bleiben kann.

Die Beispiele verwenden die aktuellen Befehle git config set/get/unset. Projektverzeichnis, Remote-URL und Dokumentations-IP sind Platzhalter. Wählen Sie für einen Test mit einem öffentlichen Repository, bei dem öffentliche Proxys erlaubt sind, einen Kandidaten aus der HTTP-Proxy-Liste.

git -C project config set --local http.proxy http://203.0.113.10:8080
git -C project ls-remote origin

Die Proxy-URL enthält ihr Transportschema. Ein HTTPS-Remote kann einen gewöhnlichen HTTP-Proxy mit CONNECT verwenden; das HTTPS-Schema des Remotes erfordert keine Umstellung der Proxy-URL auf HTTPS.

Prüfen, was Git tatsächlich ausgewählt hat

Bei einem unerwarteten Ergebnis prüfen Sie den für die tatsächliche Remote-URL ausgewählten Wert:

git -C project config get --show-origin \
  --url=https://example.com/team/project.git http.proxy

Verwenden Sie in der Abfrage Ihr echtes HTTPS-Remote. Git kann systemweite, benutzer-, repository-, kommandozeilen- und URL-spezifische Einstellungen haben. Wer nur einen globalen http.proxy-Wert betrachtet, kann eine spezifischere Regel übersehen. Die Herkunftsausgabe hilft, die Datei oder Kommandozeilenquelle hinter dem Ergebnis zu finden.

Die lokale Einstellung gilt für HTTP-basierten Zugriff aus diesem Repository, nicht nur für einen bestimmten Branch. Bei mehreren HTTP-Remotes kann sie daher auch weitere Remotes als das zuerst getestete betreffen. Für engere Zuordnung gibt es URL-spezifische HTTP-Einstellungen.

Bevor der Checkout existiert

Beim ersten Klonen entscheiden Sie, ob die Überschreibung dauerhaft gelten soll; beschränken Sie sie mit folgendem Aufruf auf diesen Git-Prozess:

git -c http.proxy=http://203.0.113.10:8080 \
  clone https://example.com/team/project.git

Die Kommandozeilenüberschreibung wird nicht von selbst zum dauerhaften Konfigurationseintrag im neuen Checkout. Setzen Sie anschließend einen lokalen Wert, wenn spätere Fetches diese Route nutzen sollen.

Ein SSH-Remote ist ein anderer Fall

Ein Remote, das mit git@host: oder ssh:// beginnt, verwendet SSH. Gits HTTP-Proxy-Einstellung macht daraus keine HTTP-Übertragung. Prüfen Sie den Transport des Remotes, bevor Sie eine funktionierende Proxy-IP austauschen, nur weil ein SSH-Vorgang weiterhin scheitert.

Wird die lokale Überschreibung nicht mehr gewünscht, entfernen Sie nur diesen Schlüssel:

git -C project config unset --local http.proxy

Dadurch kommt passende Konfiguration aus anderen Quellen wieder zum Tragen. Dies ist kein Befehl, um sämtliche Proxy-Einstellungen des Rechners zu löschen.