Перед началом любой миграции необходимо провести аудит. Что именно вы используете на GitHub? Это не только git-репозитории. Учетные данные пользователей, issues (задачи), pull requests (merge requests), wiki-страницы, проекты (projects), настройки CI/CD через GitHub Actions, webhooks, пакеты (packages) — все это нужно учесть. Простой перенос репозиториев командой `git clone --mirror` и `git push --mirror` решает лишь малую часть проблемы.
Вариант 1: GitLab Self-Managed. Это, пожалуй, самый полный и комплексный аналог. GitLab — это не просто хостинг git, а целая DevOps-платформа. Миграция может быть проведена с помощью встроенного инструмента импорта. В разделе «New Project» есть кнопка «Import project», где можно выбрать «GitHub». После авторизации через OAuth-токен GitHub можно выбрать репозитории для переноса. GitLab умеет переносить не только код, но и issues, pull requests (конвертируя их в merge requests), wiki, milestones и даже часть настроек. Для CI/CD потребуется переписать конфигурации: вместо `.github/workflows/*.yml` нужно создавать `.gitlab-ci.yml`. Это трудоемко, но дает мощный встроенный CI/CD-движок. Плюсы: максимальная функциональность, привычный интерфейс, отличная интеграция с Kubernetes. Минусы: ресурсоемкость (требует больше CPU/RAM для работы), сложность поддержки для небольшой команды.
Вариант 2: Gitea. Если нужен легковесный, простой и быстрый инструмент, максимально близкий к чистому git-хостингу, то Gitea — отличный выбор. Это форк Gogs, написанный на Go, он потребляет минимум ресурсов и легко запускается даже на слабом сервере. Прямого импорта из GitHub в интерфейсе нет, но процесс хорошо документирован. Сначала нужно создать пустой репозиторий в Gitea. Затем с машины с доступом к обоим сервисам выполнить: `git clone --mirror [URL_репозитория_на_GitHub]`, затем `cd [repo.git]` и `git push --mirror [URL_репозитория_на_Gitea]`. Issues и pull requests так не перенесешь. Для них существует отдельный инструмент миграции, доступный в веб-интерфейсе Gitea при создании репозитория (кнопка «Migrate»). Там можно указать URL GitHub-репозитория и приватный токен. Gitea умеет импортировать issues, labels, milestones и комментарии к ним. Pull requests также мигрируются. Однако CI/CD в Gitea нет «из коробки» — для этого нужно использовать сторонние решения, например, Drone CI или интеграцию с внешним Jenkins. Плюсы: легкость, скорость, низкие требования. Минусы: меньше встроенной функциональности.
Вариант 3: Forgejo. Это friendly fork Gitea, созданный в конце 2022 года сообществом разработчиков, желающих сохранить полностью открытое и управляемое сообществом развитие проекта. На текущий момент Forgejo практически идентичен Gitea по функционалу и процессу миграции, но с акцентом на независимое управление. Выбор между Gitea и Forgejo — это скорее философский вопрос о предпочтении той или иной модели развития open-source проекта. С практической точки зрения шаги миграции те же.
Общие практические шаги для любой миграции:
- Подготовка токена доступа на GitHub (Settings -> Developer settings -> Personal access tokens). Нужны права на чтение репозиториев, issues и т.д.
- Настройка нового инстанса (GitLab/Gitea/Forgejo) на своем сервере или выбор облачного предложения (например, российские хостинги предлагают готовые установки).
- Поэтапный перенос: начать с одного-двух некритических репозиториев, чтобы отработать процесс.
- Перенос CI/CD-пайплайнов: это самая сложная часть. Нужно заменить триггеры, секреты, окружения. В случае с GitHub Actions альтернативой могут быть GitLab CI, Drone, или даже локально развернутые GitHub Actions runners с собственным контроллером (например, через проект act).
- Обновление ссылок: все внутренние ссылки на коммиты, issues в коде и документации нужно обновить.
- Переключение удаленных репозиториев у разработчиков: `git remote set-url origin [новый_URL]`.
- Настройка зеркалирования (mirroring) на период перехода, чтобы изменения могли пушиться в оба места, пока миграция не завершена полностью.
Импортозамещение GitHub — это не одномоментное событие, а проект по миграции данных и процессов. Успех зависит от тщательного планирования, выбора платформы, соответствующей масштабу и потребностям команды, и фазового подхода. В результате вы получаете полный контроль над своим основным инструментом разработки, что в долгосрочной перспективе повышает устойчивость и независимость вашего IT-процесса.
Комментарии (10)