Git Clone: sett en proxy før den første fetch
Bruk konfigurasjonen ved kloning når et nytt lager trenger sin egen proxy fra den første nettverksforespørselen.
En proxy som bare gjelder lageret, høres rart ut før lageret finnes. Du trenger ikke å klone mislykket, redigere konfigurasjonen og starte på nytt.
Clone kan skrive en lokal innstilling før den første fetch:
git clone --config http.proxy=http://proxy.example.net:8080 \
https://git.example.net/team/project.git project
Disse endepunktene er eksempler. For et offentlig HTTPS-lager på en tillatt offentlig proxy-rute, velg et HTTP-endepunkt fra HTTP-proxy-listen. Git dokumenterer at dette alternativet gjelder etter at det nye lageret er initialisert og før dets eksterne historikk hentes. For denne proxy-innstillingen kan den derfor dekke den første nedlastingen og bli værende i det nye lageret etterpå.
To like kommandoer etterlater ulike spor
For å gi ruten til én enkelt kjøring uten å lagre innstillingen i det klonede lageret, sett -c før underkommandoen:
git -c http.proxy=http://proxy.example.net:8080 \
clone https://git.example.net/team/project.git project
git clone --config ... og git -c ... clone er ikke utskiftbare konfigurasjonsområder. Velg om fremtidige operasjoner i det lageret skal beholde proxyen.
Undersøk det nye lagerets lokale konfigurasjon når dette valget betyr noe. Andre bruker-, system- eller URL-spesifikke innstillinger kan fortsatt delta i den effektive politikken.
Hold passord utenfor disse eksemplene når du lagrer ruten. En verdi med legitimasjon som gis til clones konfigurasjonsalternativ, kan bli en permanent lagerinnstilling.
Dette er en HTTP-transportkonfigurasjon, inkludert HTTPS-fjernlagre. Et SSH-fjernlager trenger fortsatt sin SSH-proxy-rute; å flytte SSH til port 443 får ikke dette alternativet til å konfigurere det.