Если еще пару лет назад GitHub для большинства команд был вариантом «по умолчанию», то сегодня все чаще возникает вопрос: что делать, если репозиторий нужно держать под своим контролем и без зависимости от зарубежной платформы.

Причины у всех разные. Кто‑то закрывает требования по импортозамещению, кто‑то снижает инфраструктурные риски, кто‑то просто хочет иметь резервную площадку на случай очередных ограничений. В любом случае миграция репозитория рано или поздно становится практической задачей, а не темой для обсуждений.

В GitFlic для этого предусмотрено два сценария. Первый — импорт проекта, когда репозиторий переносится один раз вместе с историей коммитов, ветками и тегами. Второй — зеркалирование, которое позволяет поддерживать синхронизацию между GitFlic и внешним репозиторием автоматически.

В статье покажем оба варианта на практике, разберем получение токенов для GitHub, GitLab, Bitbucket и Gitea, а также расскажем о нюансах, которые стоит учесть перед переносом.

Что переносится, а что — нет

Перед миграцией важно понимать границы функционала. При базовом импорте и зеркалировании GitFlic переносит:

• все файлы проекта;

• историю коммитов;

• ветки;

• теги.

При этом не переносятся: открытые запросы на слияние, обсуждения, задачи (issues), вики и другое. Если вам нужна полная миграция с GitLab, включая MR и прочие артефакты, для этого есть отдельный инструмент — расширенный импорт с GitLab, который рассмотрим отдельно.

Зеркалирование работает иначе: оно создает синхронизированную копию репозитория без переноса мета‑данных, но зато поддерживает код в актуальном состоянии автоматически.

Способ 1: Импорт проекта

Шаг 1. Создание импорта в GitFlic

В правом верхнем углу любой страницы GitFlic нажмите на раскрывающееся меню «+» и выберите «Импорт проекта»

На странице импорта укажите:

• Ссылку на внешний проект — URL‑адрес для клонирования по протоколу HTTPS, обязательно оканчивающийся на .git.

• Логин — имя пользователя на платформе‑источнике.

• Токен — персональный токен доступа или токен развертывания (Deploy Token).

Далее заполните поля как при создании обычного проекта: название, описание, приватность.

Шаг 2. Получение токена — по платформам

GitHub

1. Перейдите на страницу github.com/settings/tokens.

2. Нажмите Generate new token.

3. В разделе прав укажите группу repo (полный доступ к репозиториям).

4. Нажмите Generate token и скопируйте результат.

В поле «Логин» на странице импорта GitFlic укажите ваш логин на GitHub, в поле «Токен» — сгенерированный токен.

GitLab

В GitLab токен создается отдельно для каждого проекта:

1. Перейдите в нужный проект → Настройки → Репозиторий → Deploy Tokens (токен развертывания).

2. Задайте название токена и выберите все необходимые права.

3. Нажмите «Создать».

В GitFlic в поле «Логин» укажите название токена, в поле «Токен» — его значение.

Bitbucket (Self‑Hosted)

1. В настройках аккаунта Bitbucket создайте токен с правами доступа к репозиторию.

2. На странице импорта GitFlic укажите ссылку на репозиторий, логин аккаунта Bitbucket и полученный токен.

Gitea

1. В настройках импортируемого проекта Gitea перейдите во вкладку «Токен развертывания» и нажмите «Добавить ключ развертывания». В Gitea нужно самостоятельно задать значение токена — для этого подойдет ваш публичный SSH‑ключ.

2. На странице импорта GitFlic укажите этот токен, в поле «Пользователь» — имя пользователя в Gitea.

Итог: что вы получите

После завершения импорта у вас будет полноценный проект в GitFlic с полной историей Git. Можно подключить CI/CD, настроить права доступа, добавить участников команды — все как при создании нового проекта.

Важно: импорт — это единоразовая операция. Если исходный репозиторий продолжает развиваться и вам нужна постоянная синхронизация, используйте зеркалирование.

Способ 2: Зеркалирование проекта

Зеркало — это проект GitFlic, который автоматически синхронизируется с внешним источником. Поддерживаются две стратегии:

• PULL — GitFlic забирает изменения из внешнего репозитория и обновляет у себя.

• PUSH — GitFlic отправляет изменения во внешний репозиторий. Это позволяет держать актуальной копию на другой платформе.

Шаг 1. Создание зеркала

Обратите внимание: для создания зеркал нужны специальные права пользователя. В Self‑Hosted версии их выдает администратор сервиса. Для облачного GitFlic необходимо обратиться в поддержку.

Нажмите на иконку «+» в верхнем меню и выберите «Новое зеркало».

Шаг 2. Настройка приватности

Публичный репозиторий: достаточно вставить ссылку на репозиторий (оканчивающуюся на .git) и заполнить остальные поля. Проект встанет в очередь на зеркалирование и обновится автоматически — обычно в течение 10 минут (без учета очереди и размера репозитория).

Приватный репозиторий: дополнительно нужно заполнить поля «Логин» и «Токен». Есть два варианта:

1. Логин — почта пользователя, токен — его пароль.

2. Создать токен развертывания (Deploy Token) для нужного проекта. Логин — псевдоним пользователя, создавшего токен, токен — его значение.

Шаг 3. Частота обновления

• В Self‑Hosted версии частота обновления зеркал настраивается администратором в панели администратора.

• В облачной версии GitFlic зеркала обновляются один раз в сутки.

Шаг 4. Зеркалирование отдельных веток и тегов (RefSpec)

Если нужно синхронизировать не весь репозиторий, а только конкретные ветки или теги, используйте настройку RefSpec. Маска поля: refs/<heads/tags>/<название>:refs/<heads/tags>/<название>.

Часть до : задает, что зеркалируется; часть после — куда.

Примеры из документации:

• Зеркалирование ветки master в ветку mymaster

  refs/heads/master:refs/heads/copy‑master

• Зеркалирование тега 3.0.0 в тег с названием tag

  refs/tags/3.0.0:refs/tags/mirror-3.0.0

• Зеркалирование ветки develop в dev и всех тегов

  refs/heads/develop:refs/heads/dev, refs/tags/*:refs/tags/*

Несколько правил указываются через запятую. Пустые ветки назначения создавать заранее не нужно — GitFlic создаст их автоматически.

Стратегия PUSH для существующего проекта

Из любого существующего проекта GitFlic можно сделать PUSH‑зеркало. Для этого в настройках проекта (раздел «Опасная зона») найдите функцию «Сделать репозиторий PUSH‑зеркалом» и укажите адрес внешнего репозитория и данные для авторизации с правами на запись.

Это удобно, например, для резервного копирования: код хранится в GitFlic, но параллельно дублируется на другую платформу или на локально развернутый GitFlic.

Как выглядит готовое зеркало

После первой синхронизации проект получит ярлык «Зеркало» и в шапке страницы появится ссылка на исходный репозиторий.

Импорт с GitLab: расширенный режим

Для команд, переходящих с GitLab, GitFlic предлагает отдельный инструмент импорта, а также массовый импорт с GitLab. Они позволяют перенести сразу несколько проектов и поддерживают более широкий набор данных. Подробнее — в официальной документации GitFlic.

Что делать после миграции

После успешного переноса репозитория рекомендуется:

1. Проверить историю коммитов — убедиться, что все ветки и теги на месте.

2. Добавить SSH‑ключ — чтобы работать с репозиторием по SSH, добавьте ключ в настройках профиля: Настройки → SSH‑ключи.

3. Обновить удаленный адрес в локальных клонах: git remote set-url origin <новый URL GitFlic>.

4. Настроить CI/CD — GitFlic имеет встроенный CI/CD на основе gitflic-ci.yaml. Подробности в документации.

5. Перенести токены и секреты — если у вас были переменные окружения или секреты в GitHub Actions / GitLab CI, добавьте их в настройках CI/CD проекта в GitFlic.

6. Настроить права доступа — пригласите участников команды и задайте роли: Управление доступом.

Сравнение способов миграции

Итоги

GitFlic поддерживает импорт из GitHub, GitLab, Bitbucket и Gitea прямо из интерфейса — без командной строки и сложных скриптов. Выбор метода зависит от задачи: если вы полностью переезжаете — используйте импорт, если хотите сохранить синхронизацию с исходным репозиторием — зеркалирование.

Статья написана на основе официальной документации GitFlic: https://docs.gitflic.ru/latest/