أعطِ Git قواعد وكيل مختلفة لمضيفين مختلفين

يمكن لإعداد Git واحد أن يخدم مسارين مختلفين تمامًا: مضيف خارجي يُبلَغ عبر وكيل معتمد، ومضيف داخلي يُبلَغ مباشرة. لست مضطرًا إلى تعديل الإعداد الافتراضي العام في كل مرة تنتقل فيها بين المستودعات.

يدعم Git إعداد HTTP المخصص لعناوين URL. على سبيل المثال:

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

بالنسبة إلى مستودع عام خارجي يُسمح فيه بالوكلاء العامين، تقدم قائمة وكلاء HTTP مرشحين لنقطة النهاية الافتراضية. القيمة الفارغة تجاوز صريح للعنوان المطابق. وهي تختلف عن حذف ذلك المفتاح الأكثر تحديدًا، وهو ما قد يعيد كشف الوكيل العام.

طابِق العنوان الذي يستخدمه Git

يشارك المخطط واسم المضيف والمنفذ والمسار واسم المستخدم الاختياري في قواعد المطابقة الموثقة. لا تتعامل مع القسم الفرعي لعنوان URL كتعبير شامل عام في الصدفة. قاعدة مسار أضيق يمكن أن تتغلب على قاعدة مضيف أوسع.

لنظرة للقراءة فقط على إعداد الوكيل المطابق:

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

يفحص هذا مطابقة الإعداد. إنه ليس اختبار شبكة ولا يثبت أن المسار قابل للوصول. خذ في الحسبان أيضًا نطاقات إعداد أخرى وإعدادات بيئة ذات صلة.

إعادة التوجيه ليست مطابقة إعداد جديدة

تقول وثائق Git إن العناوين المطابقة هي تلك المقدمة مباشرة إلى أوامر Git؛ أما العناوين التي تُزار بسبب إعادة توجيه فلا تشارك في تلك المطابقة. ضع هذا القيد في اعتبارك إذا أعاد المضيف الأول توجيه التنزيلات إلى مكان آخر.

ينبغي أن يطابق المسار وسيلة النقل أيضًا. لا يخضع مستودع SSH البعيد لقسم فرعي لعنوان HTTP لمجرد أن الخدمة نفسها تقدم موقع HTTPS.

استخدم قليلًا من القواعد المقصودة، ثم افحص النتيجة لعناوين تمثيلية. التراكم الطويل من إدخالات الوكيل العامة والمحلية بالمستودع والمخصصة للعنوان أصعب بكثير في الاستدلال من التمييز الشبكي الذي كنت تحاول التعبير عنه.