Git Clone: սահմանեք proxy մինչև առաջին fetch-ը
Օգտագործեք clone-ի ժամանակի կարգավորումը, երբ նոր պահոցին առաջին ցանցային հարցումից ի վեր սեփական proxy է պետք։
Պահոցին տեղային 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 պորտ տեղափոխելը չի ստիպում այս ընտրանքին կարգավորել այն։