Git Clone: наладзьце проксі да першага fetch

Выкарыстоўвайце канфігурацыю пры clone, калі новы рэпазітар патрабуе ўласнага проксі з першага сеткавага запыту.

Проксі, лакальны для рэпазітара, гучыць нязручна, пакуль рэпазітара няма. Не трэба рабіць няўдалы 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 дакументуе, што гэтая опцыя дзейнічае пасля ініцыялізацыі новага рэпазітара і перад загрузкай яго аддаленай гісторыі. Таму для гэтай налады проксі яна можа пакрыць першае спампоўванне і застацца ў новым рэпазітары.

Дзве падобныя каманды пакідаюць розныя сляды

Каб перадаць маршрут аднаму выкліку, не захоўваючы наладу ў скапіяваным рэпазітары, пастаўце -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 не прымусіць гэтую опцыю наладзіць яго.

Падобныя артыкулы