Ein Proxy nur für das Repository klingt unhandlich, bevor das Repository existiert. Du musst nicht erfolglos klonen, die Konfiguration bearbeiten und neu starten.

Clone kann vor dem ersten Fetch eine lokale Einstellung schreiben:

git clone --config http.proxy=http://proxy.example.net:8080 \
  https://git.example.net/team/project.git project

Die Endpunkte sind Beispiele. Für ein öffentliches HTTPS-Repository auf einer erlaubten Public-Proxy-Route wähle einen HTTP-Endpunkt aus der HTTP-Proxy-Liste. Git dokumentiert diese Option so, dass sie nach dem Initialisieren des neuen Repositorys und vor dem Abrufen der Remote-Historie wirkt. Für diese Proxy-Einstellung kann sie daher den ersten Download abdecken und danach im neuen Repository bleiben.

Zwei ähnliche Befehle hinterlassen unterschiedliche Spuren

Um die Route nur für einen Aufruf bereitzustellen, ohne diese Einstellung im geklonten Repository zu speichern, setze -c vor den Unterbefehl:

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

git clone --config ... und git -c ... clone sind keine austauschbaren Konfigurationsbereiche. Entscheide, ob spätere Operationen in diesem Repository den Proxy behalten sollen.

Prüfe die lokale Konfiguration des neuen Repositorys, wenn diese Wahl wichtig ist. Andere Benutzer-, System- oder URL-spezifische Einstellungen können weiterhin an der effektiven Richtlinie mitwirken.

Halte Passwörter aus diesen Beispielen heraus, wenn du die Route speicherst. Ein Wert mit Zugangsdaten, der an die Konfigurationsoption von clone übergeben wird, kann zu einer dauerhaften Repository-Einstellung werden.

Dies ist eine HTTP-Transport-Konfiguration, einschließlich HTTPS-Remotes. Ein SSH-Remote braucht weiterhin seine SSH-Proxy-Route; SSH auf Port 443 zu verlegen sorgt nicht dafür, dass diese Option es konfiguriert.

Ähnliche Artikel