Чому код на 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, до яких рідко заглядають: бейджі, прив'язані до провайдера, автоматичні перевірки, побудовані на жорстко вписаних URL, і посилання в документації. Усе це доводиться правити окремо. Власний домен заздалегідь знімає більшу частину цієї роботи, і зміна провайдера зводиться до редагування одного метатега та однієї цілі перенаправлення.