پروکسی محلی برای مخزن پیش از وجود مخزن عجیب به نظر می‌رسد. لازم نیست 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 باعث نمی‌شود این گزینه آن را پیکربندی کند.

مقالات مرتبط