Պահոցին տեղային proxy-ն տարօրինակ է հնչում, քանի դեռ պահոցը գոյություն չունի։ Պետք չէ անհաջող clone անել, խմբագրել config-ը և նորից սկսել։

Clone-ը կարող է տեղային կարգավորում գրել առաջին fetch-ից առաջ՝

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

Այս վերջնակետերը օրինակներ են։ Թույլատրված հանրային proxy-ի երթուղու վրա գտնվող հանրային HTTPS պահոցի համար ընտրեք HTTP վերջնակետ HTTP proxy ցանկից։ Git-ը փաստում է, որ այս ընտրանքը գործում է նոր պահոցի սկզբնավորումից հետո և մինչև դրա հեռավոր պատմության բերվելը։ Այսպիսով, այս proxy կարգավորումը կարող է ծածկել առաջին ներբեռնումը և հետո մնալ նոր պահոցում։

Երկու նման հրամաններ տարբեր հետքեր են թողնում

Երթուղին մեկ կանչին տալու համար՝ առանց կարգավորումը clone արված պահոցում պահելու, դրեք -c ենթահրամանից առաջ՝

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

git clone --config ... և git -c ... clone փոխանակելի config շրջանակներ չեն։ Ընտրեք՝ արդյոք այդ պահոցի ապագա գործողությունները պետք է պահեն proxy-ն։

Երբ այդ ընտրությունը կարևոր է, ստուգեք նոր պահոցի տեղային config-ը։ Այլ օգտատիրոջ, համակարգի կամ URL-հատուկ կարգավորումները դեռ կարող են մասնակցել արդյունավետ քաղաքականությանը։

Երթուղին պահելիս գաղտնաբառերը հեռու պահեք այս օրինակներից։ Հավատարմագրեր կրող արժեքը, որը փոխանցվում է clone-ի config ընտրանքին, կարող է դառնալ մշտական պահոցային կարգավորում։

Սա HTTP-տրանսպորտի կարգավորում է՝ ներառյալ HTTPS հեռավոր պահոցները։ SSH հեռավոր պահոցը դեռ պետք է իր SSH proxy երթուղին. SSH-ը 443 պորտ տեղափոխելը չի ստիպում այս ընտրանքին կարգավորել այն։

Առնչվող հոդվածներ