GitVerse vs GitHub - Изучаем SQL. Алан Болье

Еще на старте озадачился мыслью:

Смогу ли использовать для проекта отечественный GitVerse – аналог зарубежных сервисов GitHub и GitLab разработанный компанией СберТех?
Если да – как использовать GitHub и GitVerse в параллели с одним локальным репозиторием?

Итак, настроен один удаленный репозиторий origin, который указывает на GitHub. Чтобы отправлять код раздельно на две платформы (GitHub и GitVerse), нужно добавить GitVerse как второй удаленный репозиторий.

Регистрация

Так как СберID и GigaID у меня отсутствуют, то авторизовался в GitVerse через бесплатный аккаунт в сервисе партнера Cloud.ru на который в свою очередь зарегистрировался уже с обычной google-почтой.

1. Настроить SSH-ключ в профиле GitVerse¶

Применяем “паранойя-режим”: изолированные ключи для каждого сервиса. Репозиторий с GitHub связан по SSH-ключу id_ed25519. Для GitVerse создаем отдельный новый ключ и объясняем компьютеру, в какой ситуации какой ключ использовать.

Генерируем новый отдельный SSH ключ для GitVerse¶

Запускаем в Git Bash команду генерации. Чтобы не затереть старый ключ от GitHub – явно укажем новое имя файла id_ed25519_verse:

# -- Здесь и далее команды выполняем в Git Bash --
#  Git Bash: <YOUR_USERNAME>@<COMPUTER> MINGW64 ~


ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/id_ed25519_verse

# Вместо `your_email@example.com` пишем почту, привязанную к GitVerse
# На оба вопроса про `passphrase` жмем Enter

Флаг -f (от англ. file) задает путь и имя файла для сохраняемых ключей. Если не указать этот флаг, утилита ssh-keygen по умолчанию попытается сохранить ключ по стандартному пути (для алгоритма ed25519 это ~/.ssh/id_ed25519). Поскольку уже создан дефолтный ключ для GitHub с таким же именем, генерация без флага -f приведет к перезаписи старого ключа, из-за чего доступ к GitHub сломается.

В папке ~/.ssh/ появятся два файла:

закрытый ключ id_ed25519_verse и
открытый id_ed25519_verse.pub.

Добавляем новый ключ на GitVerse¶

Копируем содержимое публичного ключа в буфер обмена

cat ~/.ssh/id_ed25519_verse.pub | clip

Заходим на gitverse.ru –> кликаем иконку профиля –> Настройки –> Ключи SSH/GPG –> Добавить SSH ключ и вставляем в соответствующее поле.

2. Настроить SSH-конфиг (Магия разделения)¶

Теперь нужно сделать так, чтобы при обращении к GitHub система брала старый ключ, а при обращении к GitVerse – новый. Для этого создадим файл конфигурации SSH.

Создать файл ~/.ssh/config можно в любом текстовом редакторе (без расширения):

config

# Конфигурация для GitHub
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

# Конфигурация для GitVerse
Host gitverse.ru
    HostName gitverse.ru
    User git
    IdentityFile ~/.ssh/id_ed25519_verse
    IdentitiesOnly yes

Лучше использовать команду для терминала, которая создаст файл config сразу в правильном месте, без расширения и сразу запишет туда нужные настройки:

cat << 'EOF' > ~/.ssh/config
# Конфигурация для GitHub
Host github.com
	HostName github.com
	User git
	IdentityFile ~/.ssh/id_ed25519
	IdentitiesOnly yes

# Конфигурация для GitVerse
Host gitverse.ru
	HostName gitverse.ru
	User git
	IdentityFile ~/.ssh/id_ed25519_verse
	IdentitiesOnly yes
EOF

Если в будущем захотим добавить в config третий сервис

например, GitLab и решим воспользоваться этой же командой, символ > затрет настройки для GitHub и GitVerse. Для безопасного добавления (дозаписи) в конец существующего файла используем оператор >>:

cat << 'EOF' >> ~/.ssh/config

Чтобы убедиться, что файл создался правильно: в том же окне Git Bash выполним команду для просмотра содержимого:

cat ~/.ssh/config

# Должны увидеть напечатанный текст конфигурации

Иногда Windows-версия SSH в Git Bash может капризничать, если у файла конфигурации слишком свободные права. Чтобы этого избежать, выполним:

chmod 600 ~/.ssh/config

Когда создадим файл и добавим публичный ключ на сайт GitVerse, можем проверить связь одной короткой командой:

ssh -T git@gitverse.ru

Если всё настроено верно, GitVerse узнает нас, поприветствует по имени (аккаунту) Hi there, <your-account-name>! You've successfully authenticated... и закроет соединение.

3. Подружить локальный репозиторий с GitVerse¶

Настроим GitVerse как второй удаленный репозиторий, чтобы отправлять код на обе платформы независимо друг от друга.

Создаем пустой репозиторий на GitVerse¶

Зайти на gitverse.ru и войти в свой аккаунт.
Нажать кнопку Создать (знак плюса в верхнем меню) –> Новый репозиторий.
Указать имя проекта (лучше такое же, как на GitHub).
Важно: Снять галочки с пунктов Инициализировать репозиторий c README и Добавить .gitignore. Репозиторий должен быть абсолютно пустым.
Нажать Создать репозиторий.
На открывшейся странице скопировать ссылку на репозиторий.

Связываем локальный репозиторий с GitVerse¶

В стандартном шаблоне подсказки (бойлерплейт) для новых репозиториев GitVerse выведет сообщение, ориентируясь на старый стандарт Git, в котором ветка по умолчанию называлась master:

Отправка существующего репозитория из командной строки

 git remote add origin git@gitverse.ru:alexey-sm/learning-sql.git
 git branch -M master
 git push -u origin master
 
# Чтобы наглядно показать далее вывод команды `git remote -v`
# умышленно использую реальные данные вместо <плейсхолдеров>
# `alexey-sm` вместо <your-username>
# `learning-sql` вместо <repo-name>

Полностью игнорируем шаблонную инструкцию на сайте GitVerse и выполняем команды для нашей ветки main.

Открываем терминал в папке локального проекта и добавляем удаленный репозиторий GitVerse по SSH под новым именем verse:

git remote add verse git@gitverse.ru:alexey-sm/learning-sql.git

# SSH-клиент автоматически подставит нужный ключ,
# как только увидит домен `gitverse.ru`

Чтобы проверить, что все привязалось правильно, вводим команду:

git remote -v

# origin  git@github.com:magus1968/learning-sql.git (fetch)
# origin  git@github.com:magus1968/learning-sql.git (push)
# verse   git@gitverse.ru:alexey-sm/learning-sql.git (fetch)
# verse   git@gitverse.ru:alexey-sm/learning-sql.git (push)

Должны увидеть в списке и origin (GitHub), и verse (GitVerse).

Отправляем код на GitVerse¶

Отправляем нашу ветку main на GitVerse (вместо предложенной сайтом master):

git push -u verse main

# -- Увидим в терминале: --
# * [new branch]      main -> main
# branch 'main' set up to track 'verse/main'.

Так как репозиторий на GitVerse абсолютно пустой, у него нет предустановленной главной ветки. Как только выполним первый пуш git push -u verse main, GitVerse примет нашу ветку main. Поскольку она окажется первой и единственной веткой в репозитории, платформа автоматически сделает её главной (Default branch).

# Если в будущем планируем несколько веток, используем

git push -u verse --all

Возвращаем основным сервисом GitHub¶

Из-за того, что в предыдущем шаге мы использовали флаг -u, наша локальная ветка main теперь считает своим основным (дефолтным) направлением GitVerse (verse):

# branch 'main' set up to track 'verse/main'.

Чтобы основным сервисом оставался GitHub (чтобы при вводе короткой команды git push без аргументов код улетал именно на GitHub), выполним в терминале одну простую команду, чтобы вернуть привязку обратно:

git push -u origin main

# branch 'main' set up to track 'origin/main'.
# Everything up-to-date

4. Daily Workflow¶

Работаем с кодом, делаем коммиты как обычно.

# Чтобы отправить изменения на `GitHub` (основной):
git push

# Чтобы отправить изменения на `GitVerse` (зеркало):
git push verse

Если привычнее, вместо короткого git push можно отправить git push origin

5. Параллельный автодеплой¶

Настроить параллельный автодеплой статического сайта (Jupyter Book) для GitHub Pages и GitVerse Pages можно через разделение конфигурационных файлов.

Как разделить CI/CD для GitHub и GitVerse¶

Для бесконфликтной работы двух систем развертывания нужно настроить изоляцию воркфлоу. Для этого отлично подходит настройка в интерфейсе GitVerse:

Использовать конфигурацию из .gitverse/workflows.
При наличии .gitverse и .github, использовать .gitverse

Логика разделения:

GitHub абсолютно ничего не знает про папку .gitverse и её содержимое. Он всегда обращается только к .github/workflows/deploy.yml.
GitVerse, если включить указанную выше опцию, будет полностью игнорировать папку .github и выполнять только те инструкции, которые лежат в .gitverse/workflows/.

Hастройка автодеплоя для GitVerse Pages¶

Настройка в веб-интерфейсе GitVerse:

Открыть репозиторий learning-sql на GitVerse.
Перейти в Настройки –> Страницы (в левом меню):
- Включить тумблер Включить функцию.
- В поле Источник выбрать значение Воркфлоу (Workflow).
Перейти в Настройки –> Репозиторий –> CI/CD:
- Установить переключатель на опцию Использовать конфигурацию из .gitverse/workflows (При наличии .gitverse и .github, использовать .gitverse).

Создание файлов в локальном проекте¶

В корне локального репозитория создать новую директорию для GitVerse-экшенов:

# В терминале Git Bash в корне проекта:
mkdir -p .gitverse/workflows

# Переходим в созданную папку
cd .gitverse/workflows

# Создаем файл сценария
touch deploy.yaml

Флаг -p позволяет создать всю цепочку вложенных папок за один раз и не выдает ошибку, если они уже существуют.

Конфигурация файла сценария¶

В созданный файл .gitverse/workflows/deploy.yml добавляем конфигурацию, адаптированную под платформенные экшены GitVerse и структуру проекта (где исходники книги лежат в папке docs):

deploy.yml

name: Deploy Jupyter Book to GitVerse Pages

on:
  push:
    branches:
      - main
  workflow_dispatch:

env:
  NODE_OPTIONS: --dns-result-order=ipv4first
  BASE_URL: /learning-sql

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 18.x

      - name: Install Jupyter Book (via myst)
        run: npm install -g jupyter-book

      - name: Build HTML Assets
        run: jupyter-book build --html

      - name: Upload pages artifact
        uses: actions/upload-pages-artifact@v1
        with:
          path: './_build/html'

  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to GitVerse Pages
        uses: actions/deploy-pages@v1