תנו ל-Git כללי פרוקסי שונים למארחים שונים

תצורת Git אחת יכולה לשרת שני מסלולים שונים בתכלית: מארח חיצוני שאליו מגיעים דרך פרוקסי מאושר ומארח פנימי שאליו מגיעים ישירות. אין צורך לערוך את ברירת המחדל הגלובלית בכל פעם שאתם מחליפים מאגר.

Git תומך בתצורת HTTP ספציפית לכתובת. לדוגמה:

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

עבור מאגר ציבורי חיצוני שבו פרוקסים ציבוריים מותרים, רשימת פרוקסי ה-HTTP מציעה מועמדים לנקודת הקצה המוגדרת כברירת מחדל. הערך הריק הוא עקיפה מפורשת עבור הכתובת המתאימה. הוא שונה ממחיקת אותו מפתח ספציפי יותר, שעלולה לחשוף שוב את הפרוקסי הכללי.

התאימו את הכתובת שבה Git משתמש

הסכימה, שם המארח, הפורט, הנתיב ושם המשתמש האופציונלי משתתפים בכללי ההתאמה המתועדים. אל תתייחסו לסעיף הכתובת כביטוי תווים כלליים של מעטפת. כלל נתיב צר יותר יכול לגבור על כלל מארח רחב יותר.

למבט לקריאה בלבד בתצורת הפרוקסי המתאימה:

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

זה בודק התאמת תצורה. זה אינו מבחן רשת ואינו מוכיח שהמסלול נגיש. קחו בחשבון גם תחומי תצורה אחרים והגדרות סביבה רלוונטיות.

הפניה מחדש אינה התאמת תצורה חדשה

התיעוד של Git אומר שהכתובות המותאמות הן אלו שמועברות ישירות לפקודות Git; כתובות שמבקרים בהן בגלל הפניה מחדש אינן משתתפות בהתאמה הזו. זכרו את המגבלה הזו אם המארח הראשון מפנה הורדות למקום אחר.

המסלול צריך להתאים גם לתעבורה. מאגר SSH מרוחק אינו נשלט על ידי סעיף כתובת HTTP רק מפני שאותו שירות מציע אתר HTTPS.

השתמשו בכמה כללים מכוונים, ואז בדקו את התוצאה עבור כתובות מייצגות. הצטברות ארוכה של רשומות פרוקסי גלובליות, מקומיות למאגר וספציפיות לכתובת הרבה יותר קשה להבנה מההבחנה ברשת שניסיתם לבטא.