Git Clone: د لومړي fetch څخه مخکې 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 proxy لیست څخه HTTP پای ټکی وټاکئ. Git مستند کوي چې دا انتخاب وروسته له دې چې نوی ریپازیتوري پیل شي او مخکې له دې چې د هغې لیرې تاریخچه fetch شي نافذ دی. نو دا 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 ځانګړي تنظیمات لا هم کولی شي په اغېزمنه پالیسي کې برخه واخلي.

د لارې د ساتلو پر مهال پټنومونه له دې بېلګو لرې وساتئ. د credential لرونکی ارزښت چې د clone config انتخاب ته ورکړل شي کولی شي دایمي ریپازیتوري تنظیم شي.

دا HTTP-transport config دی، په شمول د HTTPS لیرې ریپازیتوري. SSH لیرې ریپازیتوري لا هم خپله SSH proxy لار ته اړتیا لري؛ SSH port 443 ته لېږدول دې انتخاب ته نه کوي چې هغه تنظیم کړي.