Почему нельзя хранить код только на GitHub: риски и выводы

GitHub как SPOF: удобно, пока не прилетело

GitHub остаётся крупнейшей площадкой для хранения кода. Это важная часть картины: у него аудитория, экосистема, интеграции, привычные пайплайны, issue-трекеры, actions, webhooks — весь этот уютный продовый сарай, который обычно никто не документирует, потому что «и так работает».

А потом репозиторий скрыт. Или сервис лежит. Или доступ меняется. И внезапно выясняется, что:

origin = github.com
backup = null
releases = github only
ci secrets = github only
docs = wiki github only
bus factor = 1

По данным Overclockers.ru, часть разработчиков открытых проектов всё чаще смотрит на Codeberg и собственные серверы. В материале также говорится, что на GitHub произошло 48 крупных сбоев, а среди причин миграции называют желание снизить зависимость от крупных технологических компаний и недовольство активным внедрением ИИ-инструментов.

Да, это не значит «все срочно бегут». Это значит, что нормальная инженерная команда перестаёт путать хостинг кода с инфраструктурной стратегией.

Codeberg и self-hosted — не магия, а второй контур

Codeberg, по данным источника, работает под управлением некоммерческой организации Codeberg e.V. и использует Forgejo — ответвление Gitea. Финансирование идёт через пожертвования и членские взносы сообщества. Для части open source-разработчиков важны открытый исходный код самой платформы и отсутствие рекламной модели.

Звучит чище, чем очередной корпоративный комбайн. Но не надо романтики. Любая альтернатива — это эксплуатация. Доступы, зеркалирование, релизы, webhooks, CI, права, токены, восстановление. Иначе это не отказоустойчивость, а костыль с красивым README.

Многие проекты, как отмечает Overclockers.ru, не уходят с GitHub полностью: они синхронизируют репозитории на нескольких площадках или используют Codeberg как основное место разработки, сохраняя GitHub ради охвата. Вот это уже похоже на взрослую схему. Не «сжечь всё», а убрать single point of failure.

Принцип банальный: не держать всё в одном активе. Даже люди, которые собирают дивидендные акции и пассивный доход, обычно понимают диверсификацию быстрее, чем разработчик, у которого единственная копия production-кода лежит в одном remote.

Что проверить сейчас, пока не пятница вечер

Минимальный чек без шаманства:

git remote -v
git branch -a
git tag -l

Если видите только один origin, это не архитектура. Это вера.

Добавьте зеркало:

git remote add mirror <second-repo-url>
git push --mirror mirror

Проверьте, что теги, ветки и история реально уехали:

git ls-remote mirror

Отдельно выгрузите релизы, артефакты, документацию и issue-данные, если они критичны. Сам git не спасёт то, что вы прибили к веб-интерфейсу платформы. CI-секреты тоже не телепортируются. Их надо описать, заротировать и хранить так, чтобы восстановление не зависело от одного аккаунта с потерянным 2FA.

И главное: протестируйте восстановление. Не «у нас есть зеркало», а реально:

git clone <second-repo-url>
cd repo
make test
make build

Если проект собирается только из старого GitHub-окружения — это не сборка, а спиритический сеанс. Делайте бэкапы. Проверяйте зеркала. И не называйте инфраструктурой то, что исчезает вместе с одной скрытой страницей.