توجيه البروكسي لوحدات Git الفرعية

نجاح استنساخ المستودع الرئيسي لا يختبر وحداته الفرعية. فالوحدة الفرعية مستودع Git آخر، ربما على مضيف آخر وبوسيلة نقل مختلفة.

ابدأ بقراءة العناوين المعلنة:

git -C project config --file .gitmodules --get-regexp '^submodule\..*\.url$'
git -C project submodule status --recursive

قد يحتوي مستودع أب جُلب عبر HTTPS على وحدة فرعية تستخدم git@host:. إعداد بروكسي HTTP لا يضبط اتصال SSH ذاك. ويجب أيضًا حل العناوين النسبية للوحدات الفرعية بالنسبة إلى المستودع البعيد المناسب للمشروع الأعلى، لا إلى عنوان ويب افترضته من اسم المشروع.

للإعدادات المحلية نطاق محدد

ينتمي إدخال http.proxy المحلي إلى المستودع الذي يحتوي ملف إعداده عليه. لا تفترض أن فحص الأب وحده يكشف كل الإعدادات الفعلية داخل مستودع تابع جرت تهيئته.

لتعيين بروكسي HTTPS مؤقتًا خلال تحديث تكراري، يمكنك تمرير إعداد Git من سطر الأوامر إلى ذلك الاستدعاء:

git -C project -c http.proxy=http://203.0.113.10:8080 \
  submodule update --init --recursive

استبدل نقطة الاتصال التوضيحية. للوحدات الفرعية العامة عبر HTTPS وعلى مسار يسمح بالبروكسيات العامة، توفر قائمة بروكسيات HTTP عناوين مرشحة. هذا لا يحوّل عناوين الوحدات الفرعية من SSH إلى HTTPS، وتظل الإعدادات الأدق المرتبطة بالعنوان جديرة بالفحص إذا كان المسار المختار غير متوقع.

عندما يتغير العنوان المسجل

يسجّل Git إعداد الوحدة الفرعية محليًا أثناء التهيئة. إذا تغير عنوانها في المشروع، فقارن التصريح الحالي بالقيمة المسجلة محليًا قبل الحكم بأن البروكسي معطل. تحدّث عملية sync الموثقة العناوين المسجلة من تصريح المشروع؛ وهي ليست بحد ذاتها إعدادًا لبروكسي الشبكة.

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

افصل أخطاء النقل عن أخطاء المستودع. فالتزام غير متاح، ورفض المستودع الوصول، وفشل الاتصال بالبروكسي أسباب مختلفة للنتيجة العامة نفسها: «submodule update failed».