Git Clone: დააყენეთ პროქსი პირველ fetch-ამდე

რეპოზიტორიის ლოკალური პროქსი უხერხულად ჟღერს, სანამ რეპოზიტორია არსებობს. არ არის საჭირო წარუმატებლად clone-ი, კონფიგის რედაქტირება და თავიდან დაწყება.

Clone-ს შეუძლია პირველ fetch-ამდე ლოკალური პარამეტრის ჩაწერა:

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

ეს ბოლო წერტილები მაგალითებია. დაშვებულ საჯარო პროქსის მარშრუტზე მდებარე საჯარო HTTPS რეპოზიტორიისთვის აირჩიეთ HTTP ბოლო წერტილი HTTP პროქსის სიიდან. Git ადასტურებს, რომ ეს ოპცია ძალაშია ახალი რეპოზიტორიის ინიციალიზაციის შემდეგ და მისი დისტანციური ისტორიის მოტანამდე. ამიტომ ეს პროქსის პარამეტრი შეიძლება მოიცავდეს პირველ ჩამოტვირთვას და შემდეგ დარჩეს ახალ რეპოზიტორიაში.

ორი მსგავსი ბრძანება სხვადასხვა კვალს ტოვებს

მარშრუტის ერთ გამოძახებაზე მისაწოდებლად პარამეტრის 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 ურთიერთშემცვლელი კონფიგურაციის არეები არ არის. აირჩიეთ, უნდა შეინარჩუნოს თუ არა ამ რეპოზიტორიის მომავალმა ოპერაციებმა პროქსი.

როცა ეს არჩევანი მნიშვნელოვანია, შეამოწმეთ ახალი რეპოზიტორიის ლოკალური კონფიგურაცია. სხვა მომხმარებლის, სისტემის ან URL-სპეციფიკური პარამეტრები კვლავ შეიძლება მონაწილეობდეს ეფექტურ პოლიტიკაში.

მარშრუტის შენახვისას პაროლები ამ მაგალითებს მიღმა დაიტოვეთ. clone-ის კონფიგურაციის ოპციაზე გადაცემული რწმუნებების მქონე მნიშვნელობა შეიძლება გახდეს რეპოზიტორიის მუდმივი პარამეტრი.

ეს HTTP ტრანსპორტის კონფიგურაციაა, მათ შორის HTTPS დისტანციური რეპოზიტორიები. SSH დისტანციურ რეპოზიტორიას კვლავ სჭირდება საკუთარი SSH პროქსის მარშრუტი; SSH-ის 443 პორტზე გადატანა არ იწვევს ამ ოპციის მიერ მის კონფიგურაციას.