یک پیکربندی Git می‌تواند دو مسیر کاملاً متفاوت را سرویس دهد: میزبان خارجی که از طریق پروکسی تأییدشده به‌دست می‌آید و میزبان داخلی که مستقیم به‌دست می‌آید. لازم نیست هر بار که مخزن را عوض می‌کنید پیش‌فرض سراسری را ویرایش کنید.

Git پیکربندی HTTP مخصوص URL را پشتیبانی می‌کند. برای نمونه:

[http]
    proxy = http://proxy.example:8080
[http "https://git.office.example/"]
    proxy =

برای یک مخزن عمومی خارجی که پروکسی‌های عمومی در آن مجاز است، فهرست پروکسی HTTP نامزدهایی برای نقطه پایانی پیش‌فرض ارائه می‌دهد. مقدار خالی یک بازنویسی صریح برای URL منطبق است. این با حذف آن کلید خاص‌تر تفاوت دارد، کاری که می‌تواند پروکسی عمومی را دوباره آشکار کند.

URL مورد استفاده Git را تطبیق دهید

طرح‌واره، نام میزبان، درگاه، مسیر و نام کاربری اختیاری در قواعد تطبیق مستندشده شرکت می‌کنند. زیربخش URL را به‌عنوان یک عبارت عام shell با نویسه‌های عام در نظر نگیرید. یک قاعده مسیر باریک‌تر می‌تواند بر قاعده میزبان گسترده‌تر پیروز شود.

برای نگاهی فقط‌خواندنی به پیکربندی پروکسی منطبق:

git config --get-urlmatch http.proxy https://git.office.example/team/project.git

این تطبیق پیکربندی را بررسی می‌کند. آزمون شبکه نیست و ثابت نمی‌کند که مسیر قابل دسترسی است. دامنه‌های پیکربندی دیگر و تنظیمات محیطی مرتبط را نیز در نظر بگیرید.

تغییرمسیر یک تطبیق پیکربندی جدید نیست

مستندات Git می‌گوید URL‌های منطبق همان‌هایی هستند که مستقیماً به فرمان‌های Git داده می‌شوند؛ URL‌هایی که به‌دلیل تغییرمسیر بازدید می‌شوند در آن تطبیق شرکت نمی‌کنند. اگر میزبان نخست دانلودها را جای دیگری تغییرمسیر دهد این محدودیت را در نظر داشته باشید.

مسیر باید با روش انتقال هم بخواند. یک مخزن دور SSH فقط به این دلیل که همان سرویس یک وب‌سایت HTTPS ارائه می‌دهد تحت زیربخش URL HTTP نیست.

چند قاعده عامدانه به کار ببرید، سپس نتیجه را برای URL‌های نماینده بررسی کنید. انباشت طولانی ورودی‌های پروکسی سراسری، محلی مخزن و مخصوص URL بسیار سخت‌تر از تمایز شبکه‌ای است که می‌خواستید بیان کنید.

مقالات مرتبط