अलग-अलग होस्ट के लिए Git को अलग प्रॉक्सी नियम दें

एक Git कॉन्फ़िगरेशन दो बिल्कुल अलग मार्गों पर सेवा दे सकता है: स्वीकृत प्रॉक्सी के माध्यम से पहुँचा गया बाहरी होस्ट और सीधे पहुँचा गया आंतरिक होस्ट। हर बार रिपॉज़िटरी बदलने पर वैश्विक डिफ़ॉल्ट संपादित करने की आवश्यकता नहीं है।

Git URL-विशिष्ट HTTP कॉन्फ़िगरेशन का समर्थन करता है। उदाहरण के लिए:

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

ऐसे बाहरी सार्वजनिक रिपॉज़िटरी के लिए जहाँ सार्वजनिक प्रॉक्सी की अनुमति है, HTTP प्रॉक्सी सूची डिफ़ॉल्ट एंडपॉइंट के लिए उम्मीदवार देती है। खाली मान मेल खाते URL के लिए स्पष्ट ओवरराइड है। यह उस अधिक विशिष्ट कुंजी को हटाने से भिन्न है, जो सामान्य प्रॉक्सी को फिर से उजागर कर सकता है।

Git जिस URL का उपयोग करता है उसका मिलान करें

स्कीम, होस्टनाम, पोर्ट, पथ और वैकल्पिक उपयोगकर्ता नाम प्रलेखित मिलान नियमों में भाग लेते हैं। URL उपखंड को सामान्य shell वाइल्डकार्ड अभिव्यक्ति न मानें। संकरा पथ नियम व्यापक होस्ट नियम को हरा सकता है।

मेल खाते प्रॉक्सी कॉन्फ़िगरेशन पर केवल-पढ़ने के दृश्य के लिए:

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

यह कॉन्फ़िगरेशन मिलान की जाँच करता है। यह नेटवर्क परीक्षण नहीं है और यह सिद्ध नहीं करता कि मार्ग पहुँच योग्य है। अन्य कॉन्फ़िगरेशन दायरों और प्रासंगिक परिवेश सेटिंग्स को भी ध्यान में रखें।

रीडायरेक्ट नया कॉन्फ़िगरेशन मिलान नहीं है

Git का दस्तावेज़ कहता है कि मिलान किए गए URL वे हैं जो सीधे Git कमांड को दिए जाते हैं; रीडायरेक्ट के कारण देखे गए URL उस मिलान में भाग नहीं लेते। यदि पहला होस्ट डाउनलोड कहीं और रीडायरेक्ट करता है तो यह सीमा ध्यान में रखें।

मार्ग को परिवहन से भी मेल खाना चाहिए। SSH रिमोट केवल इसलिए HTTP URL उपखंड द्वारा नियंत्रित नहीं होता कि वही सेवा HTTPS वेबसाइट देती है।

कुछ जानबूझकर बनाए गए नियम उपयोग करें, फिर प्रतिनिधि URL के लिए परिणाम जाँचें। वैश्विक, रिपॉज़िटरी-स्थानीय और URL-विशिष्ट प्रॉक्सी प्रविष्टियों का लंबा संचय उस नेटवर्क भेद से कहीं अधिक समझना कठिन है जिसे आप व्यक्त करना चाह रहे थे।