למה לא כדאי לכבול את קוד ה-Go ל-GitHub

ל-Go יש תכונה יוצאת דופן בין שפות התכנות: נתיב הייבוא של חבילה הוא גם הכתובת שממנה הכלים מורידים את הקוד שלה. אם ספרייה מתארחת בכתובת github.com/example/thing, המחרוזת הזו מופיעה כמות שהיא בכל קובץ שמייבא אותה. ברשומה שפורסמה ב-27 בספטמבר 2026 טוען המהנדס Iain Cambridge שהנוחות הזו כובלת בשקט פרויקט Go לספק אחסון אחד, ושצוותים צריכים למקם את המודולים שלהם תחת דומיין משלהם.

מאין נוצרת הכבילה

בלב הבעיה עומדת העובדה שכתובת אחסון ה-git הופכת לנתיב המודול, וכך נקשר הקוד לאחסון הזה. אם מעבירים מאגר ל-GitLab, ל-Codeberg או לשרת עצמאי, יש לכתוב מחדש כל נתיב ייבוא, כל רשומה ב-go.mod וכל הוראת replace שמזכירה את הכתובת הישנה, אחרת הכלים ימשיכו להוריד את העותק הישן. לדברי המחבר, התקורה של המעבר גדולה כל כך שחברות פשוט מפסיקות לעשות זאת, והקוד נשאר כבול ל-GitHub.

הוא מתאר חברה שעבדה במקביל על GitLab, GitHub ו-Azure DevOps. העברת הקוד הייתה משימה כה גדולה, ולצוות היה כל כך מעט זמן, שהפעלה של שלוש פלטפורמות במקביל הייתה קלה יותר מאיחודן. המחיר היה מוחשי: החברה שילמה עבור שלושה שירותי אחסון בו-זמנית. לדברי Cambridge, הניסיון הזה הוא הסיבה שבנה את Boneclone, כלי שמשכפל קוד שלד בין כמה פלטפורמות אחסון git בעת ובעונה אחת.

הפתרון הוא לפרסם מודולים תחת דומיין משלהם, בדפוס שבו משתמשים go.uber.org, go.mongodb.org וגם go.iain.rocks של המחבר. הדומיין הוא נתיב הייבוא, ומאחוריו אותה כתובת יכולה להצביע למקום שבו הקוד נמצא כעת. go.iain.rocks/boneclone מפנה היום ל-github.com/thetrueares/boneclone, ואם המאגר יעבור ל-GitLab, המשתמשים יתקינו אותו באותה פקודה ולא יבחינו בהבדל. לדעתו, כל צוות פיתוח מסחרי שמשתמש ב-Go צריך לתת שמות כאלה לספריות ולחבילות הפנימיות שלו.

הדומיין שלכם, לא האחסון

המנגנון כבר מובנה בשפה: כשהכלי מבקש נתיב עם הפרמטר go-get=1, השרת מחזיר עמוד HTML קצר עם תג מטא go-import שמציין את כתובת המאגר. אצל המחבר הרשומה נראית כך: go.iain.rocks/boneclone git https://github.com/that-guy-iain/boneclone, ולצידה תג go-source שעוזר לעורכים לבנות קישורים לקבצים. תצורת ה-Nginx שלו מגישה את העמוד הזה לכלי Go, ומפנה מבקרים אנושיים ל-GitHub בקוד 301.

איך נראית התצורה

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