Як перенести дані з Gitea у Forgejo, не пошкодивши репозиторії

Ви зупиняєте Gitea, встановлюєте Forgejo, копіюєте app.ini і каталог даних, запускаєте сервіс так, як описує кожен посібник з міграції. Веб-UI піднімається. А потім міграція бази даних падає з помилкою, або, ще гірше, Forgejo відмовляється запускатися, бо версія вашої схеми занадто нова для розуміння. Ви на Gitea 1.23 чи новіше, і простий шлях оновлення на місці, який усі документують, до вас більше не застосовний.

Forgejo став жорстким форком Gitea на початку 2024 року, і відтоді обидва проєкти розійшлися на рівні схеми бази даних. Те, як ви переносите дані з Gitea у Forgejo, тепер повністю залежить від вашої версії Gitea. Цей гайд дає точний шлях для вашої версії, повні команди для нативних і Docker-встановлень, обхідні рішення для Gitea 1.23+ та контрольний список перевірки, щоб ви перенесли дані без втрати репозиторіїв, issue чи користувачів.

TL;DR

• Версійний обрив справді існує. Forgejo v10.0 був останнім релізом, що підтримував прозоре пряме оновлення з Gitea. Gitea v1.22, найвища версія, яка може пройти підтримуваний прямий шлях.
• На Gitea v1.22 або раніше: спочатку мігруйте на Forgejo v10.0.x, потім оновіть Forgejo v10 до поточного релізу (v15). Два кроки, обидва підтримувані.
• На Gitea v1.23 або новіше: офіційно підтримуваного прямого шляху не існує. Ви обираєте між пониженням SQL/схеми, скриптами міграції від спільноти, міграцією через репозиторій/API або розгортанням на новому сервері з використанням одного з цих методів. Кожен несе свій компроміс щодо втрати даних.
• Зробіть резервну копію каталогу даних і бази даних, перш ніж щось чіпати. Кожен шлях нижче передбачає наявність відновлюваної резервної копії. Непідтримувані шляхи вимагають цього подвійно.
• Деякі речі завжди потребують уваги після міграції: плануйте відтворити або перевірити Personal Access Tokens, повторно зареєструвати runner'и Actions і видалити та перебудувати пошуковий індекс Bleve. Плануйте це незалежно від обраного шляху.
• Міграція не є обов'язковою. Gitea активно підтримується. Рішення «залишитися на Gitea» має сенс, якщо ризик міграції переважує вигоду для вашої ситуації.

Поза межами цього матеріалу: міграція з Gogs, GitHub або GitLab на Forgejo, а також налаштування Forgejo Actions з нуля.

Передумови / що вам знадобиться

Перш ніж виконати хоч одну команду, переконайтеся, що у вас є повна, відновлювана резервна копія двох речей: каталогу даних Gitea (/var/lib/gitea за стандартного нативного встановлення) і вашої бази даних. Якщо ваша база даних SQLite, цей файл знаходиться всередині каталогу даних; якщо це PostgreSQL або MySQL, зробіть окремий дамп за допомогою pg_dump або mysqldump. Міграція без перевіреної резервної копії, це не міграція, це азартна гра.

Вам також знадобиться:

• Ваша поточна версія Gitea. Виконайте gitea --version (або docker exec <container> gitea --version). Саме це число визначає весь ваш подальший шлях.
• Ваш тип бази даних: SQLite, PostgreSQL або MySQL. Деякі обхідні шляхи специфічні для конкретної бази даних.
• Доступ root або sudo на сервері.
• Розуміння того, що підтримуваний шлях передбачає встановлення Forgejo v10.0 як проміжного етапу. Forgejo v10.0 має статус EOL з 16 квітня 2025 року. Ви встановлюєте його лише на час міграції і одразу після цього оновлюєтесь до наступної версії.

Чому зламався шлях прямого оновлення

У грудні 2024 року проєкт Forgejo опублікував заява про сумісність провели чітку межу: "Майбутні версії Forgejo не підтримуватимуть оновлення з екземплярів Gitea, що працюють на версії v1.23 або новіше". Це речення уся проблема в одному рядку.

Коли Forgejo відгалузилася від Gitea на початку 2024 року, дві кодові бази продовжували розходитися, а схеми баз даних дедалі більше відрізнялися. Forgejo підтримувала вікно сумісності, щоб наявні оператори Gitea могли перейти, але це вікно мало кінець. Forgejo v10.0, випущена 16 січня 2025 року, була "the last version to allow a transparent upgrade from Gitea v1.22 or lower." Будь-яка версія новіша за v10.0 не зможе напряму прочитати базу даних Gitea.

Саме терміни збивають людей з пантелику. Gitea v1.23 вийшла наприкінці 2024 року, і поточний реліз Gitea станом на червень 2026 року це v1.26.4. Якщо ви підтримували свій екземпляр Gitea у відносно актуальному стані, ви вже перебуваєте за межею, і стандартні туторіали більше не описують вашу ситуацію.

Висновок розділу: підтримуваний прямий шлях обмежується Gitea v1.22. Усе новіше потребує додаткового кроку.

Знайдіть свій шлях міграції за версією Gitea

Виконайте gitea --version, знайдіть свій рядок і дотримуйтесь шляху в третій колонці. Все інше в цьому гайді, деталі, що стоять за цими рядками.

Заяви про сумісність версій походять безпосередньо з офіційне оголошення про сумісність Forgejo: Gitea до v1.21 можна перенести на Forgejo v7.0–v10.0, а Gitea v1.22 можна перенести на Forgejo v8.0–v10.0. Обидва варіанти обмежені v10.0 як останньою підтримуваною прямою ціллю.

Під питанням версії ховаються три стратегії міграції, і корисно розглянути їх перед покроковими інструкціями:

• На місці, той самий сервер. Замініть бінарний файл або образ контейнера на наявному сервері. Найменше зусиль, якщо ваша версія це підтримує; вимагає проміжного кроку через v10.0.
• Підготовка на новому сервері. Розгорніть новий сервер і використовуйте його як безпечну ціль для методу міграції, що відповідає вашій версії Gitea. Це захищає оригінальний сервер Gitea і полегшує відкат, але не обходить проблему схеми бази даних Gitea 1.23+.
• Міграція через репозиторій/API. Використайте інструменти міграції Forgejo, щоб забрати репозиторії зі старого екземпляра Gitea. Історія Git це надійна частина; метадані, як-от issues, PR, мітки, релізи, дані wiki та коментарі, слід сприймати як спробу "найкращих зусиль" і перевіряти по кожному репозиторію окремо.

Підтримуваний шлях: Gitea v1.22 або раніше

Якщо ви на Gitea v1.22 або раніше, то офіційна документація з міграції описують двоетапний шлях: спочатку міграція на Forgejo v10.0.x, потім оновлення Forgejo v10 до поточного релізу. Перший крок пряма заміна, бо Forgejo v10.x читає базу даних Gitea v1.22; другий крок звичайне оновлення Forgejo.

Є два способи це зробити, залежно від того, як Gitea працює на вашому сервері. Оберіть той, що відповідає вашій наявній конфігурації. Якщо Gitea працює як системний сервіс, використовуйте нативний шлях. Якщо Gitea працює в контейнері, використовуйте шлях через Docker. Forgejo v10.x діє як пряма заміна для Gitea v1.22.x.

Нативний шлях (systemd)

Спочатку зробіть резервну копію. Потім встановіть Forgejo v10.0.x, використовуючи пакет вашого дистрибутива або бінарний файл релізу, закріплений на v10.0. Зупиніть Gitea перед тим, як щось копіювати. Служба, що продовжує писати в свій каталог даних під час копіювання, пошкодить копію.

# Stop the running Gitea service before touching its data
systemctl stop gitea

Скопіюйте конфігурацію та каталог даних у відповідні місця Forgejo, потім виправте права власності. Конфігураційний файл має бути доступним для читання групою forgejo; дані мають належати користувачу forgejo.

# Copy the existing Gitea config to Forgejo's config path
cp /etc/gitea/app.ini /etc/forgejo/app.ini

# Back up the copied config before rewriting paths
cp /etc/forgejo/app.ini /etc/forgejo/app.ini.bak

# Update old Gitea data paths to Forgejo data paths
sed -i 's#/var/lib/gitea#/var/lib/forgejo#g' /etc/forgejo/app.ini

# Forgejo reads its config as the forgejo group; grant group write
chown root:forgejo /etc/forgejo/app.ini && chmod g+w /etc/forgejo/app.ini

# Copy the data directory and hand ownership to the forgejo user
rsync -aHAX --numeric-ids /var/lib/gitea/ /var/lib/forgejo/
chown -R forgejo:forgejo /var/lib/forgejo

Запустіть Forgejo і увімкніть автозапуск.

# Start Forgejo and enable it at boot
systemctl start forgejo && systemctl enable forgejo

Перш ніж оновлюватися з v10.0, очистіть черги, щоб під час стрибка версії не втратилася жодна незавершена робота.

# Flush pending queue items before the version upgrade
forgejo manager flush-queues

Тепер оновіть Forgejo v10.0.x до поточного релізу, замінивши бінарний файл на v15 і перезапустивши службу, дотримуючись стандартного Гайд з оновлення Forgejo. Після обох переходів запустіть doctor, щоб перевірити базу даних і виправити те, що можливо.

# Check everything; write a log you can read if something is wrong
forgejo doctor check --all --log-file /tmp/doctor.log

Читайте /tmp/doctor.log перед застосуванням будь-якого автоматичного виправлення. Використайте --fix лише коли вивід doctor вказує на конкретне виправлення, суть якого ви розумієте, або коли ви дотримуєтеся офіційного шляху усунення несправностей.

Якщо doctor не повідомляє про критичні помилки, а веб-інтерфейс відображає ваші репозиторії, перший етап міграції завершено.

Шлях Docker / контейнера

Якщо Gitea працювала як контейнер, запускайте Forgejo так само. Використайте образ Forgejo v10.x як пряму заміну вашого образу Gitea v1.22.x, вказавши той самий том даних і базу даних. Спочатку переконайтеся, що ваша версія Docker не нижча за 20.10.6. Старіші версії спричиняють непередбачувану поведінку з контейнерами Forgejo.

Одна деталь, специфічна для контейнерів, яка збиває людей з пантелику: змінні середовища. Forgejo зберігає префікс GITEA_ для сумісності, але документація рекомендує передавати обидва префікси, щоб ваша конфігурація пережила майбутню версію Forgejo, яка відмовиться від старих назв.

# docker-compose.yml (excerpt): pass both prefixes for forward compatibility
environment:
  - GITEA__database__DB_TYPE=postgres
  - FORGEJO__database__DB_TYPE=postgres
  # ...repeat the dual-prefix pattern for every config override you pass

Для rootless-контейнерів дані мають належати користувачу 1000 і групі 1000, що відповідає користувачу виконання rootless-образу. Після запуску контейнера на v10.x виконайте той самий forgejo doctor check --all зсередини контейнера, потім оновіть тег образу до поточного релізу v15 і перезапустіть.

Якщо ви на Gitea v1.23 або новішій версії

Тут стандартні посібники зупиняються, і саме тут насправді перебуває більшість актуальних інсталяцій. Офіційно підтримуваного прямого шляху з Gitea v1.23+ не існує, тож кожен варіант нижче або зроблений спільнотою, або пов'язаний із втратою даних. Перш ніж запускати будь-який з них, зробіть повну резервну копію каталогу даних і бази даних та переконайтеся, що можете її відновити. Ці підходи змінюють продакшн-дані; резервна копія це ваша єдина можливість скасувати зміни.

Ці три варіанти відрізняються ризиком і тим, скільки вони зберігають. Обирайте той, чий компроміс для вас прийнятний.

Варіант A: пониження версії схеми SQL / патч версії

Найвужчий обхідний шлях понижує версію схеми бази даних, щоб Forgejo v10 сприймав її як базу даних v1.22.

Примітка: не сприймайте оновлення версії як повне пониження саме по собі. Записана версія міграції та фактична схема мають збігатися. На Gitea 1.23.x спочатку протестуйте повне пониження на копії і порівняйте схему, перш ніж спрямовувати на неї Forgejo.

Мейнтейнер Forgejo описав SQL у Codeberg issue #7638:

-- Downgrade the recorded schema version to the v1.22 baseline (PostgreSQL/MySQL)
UPDATE version SET version=305 WHERE id=1;

Після цього ви дотримуєтесь підтримуваного шляху так, ніби перебуваєте на v1.22. Важливе застереження: мейнтейнер підтвердив це конкретно лише для Gitea v1.23.1, а не для всієї гілки v1.23.x. Номер версії схеми точний; застосування неправильного цільового значення до неправильного релізу Gitea може залишити базу даних у стані, з якого жодна міграція не відновить її. Це стосується PostgreSQL/MySQL, це офіційно не підтримується і не тестувалося як загальна процедура.

Порада: встановлення version=305 напряму пропускає міграцію 304→305, яка змінила спосіб кодування секретів TOTP. Codeberg issue #8210 документує, що це пошкоджує двофакторну автентифікацію для постраждалих користувачів. Виправлення полягає в тому, щоб встановити версію 304, дати міграції відпрацювати, або очистити рядки таблиці two_factor, щоб користувачі повторно налаштували автентифікацію. Не пропускайте цей крок, якщо хоч один обліковий запис використовує TOTP.

Варіант B: послідовні скрипти пониження SQL (Gitea 1.24–1.25.2)

Для версій між 1.24 і 1.25.2 одного патча версії недостатньо: схема пройшла через кілька проміжних станів. Скрипти спільноти за адресою xlrl/prepare-gitea-migration-to-forgejo проводять схему назад через проміжні версії до v1.22, після чого ви йдете підтримуваним шляхом. Ці скрипти робота спільноти, а не офіційна процедура, і орієнтовані переважно на SQLite. Запускайте їх лише на базі даних, резервну копію якої ви вже зробили.

Варіант C: міграція через API по одному репозиторію (Gitea 1.26+ або будь-яка версія)

Шлях через репозиторій/API найнадійніше зберігає дані Git. Залежно від джерела, прав доступу та методу міграції, також можуть бути доступні опціональні метадані, як-от issues, pull request'и, мітки, milestone'и, релізи, дані wiki та коментарі, але сприймайте це як спробу "найкращих зусиль" і перевіряйте по кожному репозиторію окремо. Для архіву, що містить лише код, це зазвичай прийнятно; для сервера, де issue-трекер це пам'ять команди, протестуйте перенесення метаданих, перш ніж обирати цей шлях.

Два експериментальні інструменти намагаються забезпечити повнішу міграцію для 1.23+, але мають власні прогалини. pacnpal/gitea2forgejo (GitHub) робить повний дамп плюс синхронізацію через API і потребує відповідного SECRET_KEY для передачі зашифрованих полів, але не переносить Personal Access Tokens, Actions runners, callback URL вебхуків або 2FA. nicoverbruggen/gitea-to-forgejo (GitHub) це експериментальний інструмент на основі Podman, який переносить користувачів, ключі, організації, репозиторії, issues, PR, релізи та дзеркала, але не токени 2FA, дані виконання Actions чи «висячі» маніфести пакетів OCI. Ставтеся до обох як до експериментальних і перевіряйте результат за таблицею перенесення нижче.

Висновок розділу: офіційно підтримуваного прямого шляху з Gitea 1.23+ немає. Обирайте варіант, компроміс щодо втрати даних якого для вас прийнятний, і зробіть резервну копію перед початком.

Міграція на новому сервері безпечніша, але вона не обходить межу версій

Новий сервер, найбезпечніше місце для підготовки та перевірки міграції, але це не окремий шлях сумісності схем. Якщо ваше джерело, Gitea v1.22 або раніше, спочатку встановіть Forgejo v10.0.x на цільовому сервері, відновіть або скопіюйте туди дані Gitea, дайте Forgejo виконати підтримувані міграції бази даних, а потім оновіть цей екземпляр Forgejo v10 до поточного релізу Forgejo.

Якщо ваше джерело, Gitea v1.23 або новіша версія, не відновлюйте базу даних Gitea напряму в поточному Forgejo, очікуючи, що вона запуститься. Вам все одно потрібен один із непідтримуваних підходів для 1.23+, описаних вище: поетапне пониження або відкат SQL, інструмент міграції спільноти чи міграція через репозиторій/API. Новий сервер знижує ризик відкату, оскільки оригінальний сервер Gitea залишається недоторканим; але це не усуває потреби вирішити невідповідність версії бази даних.

Саме тут Cloudzy Forgejo в один клік застосунок може допомогти: використайте його як чистий цільовий екземпляр, а потім запустіть метод міграції, що відповідає вашій версії Gitea. Образ з маркетплейсу Cloudzy надає готову ціль Forgejo на нашому високопродуктивних VPS, тож ви можете зосередитися на відновленні, перевірці та кроках переходу, а не на початковому встановленні. План міграції все одно залежить від того, перебуваєте ви до чи після межі Gitea 1.22.

Що переноситься, а що доведеться робити заново

Частина ваших даних переноситься автоматично, частина лише за певної умови, а частина ніколи не переноситься і має бути відтворена вручну. Знання того, що є що, перед початком, це різниця між чистим переходом і тижнем розгублених користувачів.

Чотири пункти б'ють найсильніше, тому що ламаються тихо або впливають на кожного користувача, тож поводьтеся з ними свідомо: користувачі мають перестворити або перевірити свої Personal Access Tokens, вам потрібно повторно зареєструвати Actions runners під нове ім'я хоста, потрібно видалити пошуковий індекс Bleve, щоб Forgejo чисто перебудував його, і потрібно переписати будь-які uses: короткі посилання у ваших workflow Actions на повні URL GitHub, бо Forgejo і Gitea тягнуть actions з окремих дзеркал, і відносне посилання веде не туди.

Порада: якщо під час міграції ви запускаєте Gitea і Forgejo паралельно, і обидва вказують на той самий екземпляр Redis, змініть Forgejo на Redis db=1 перед початком. Обидва за замовчуванням використовують db=0, і якщо вони діляться ним, Gitea споживає події міграції Forgejo та руйнує чергу міграції. (blog.mei-home.net documents this exact failure.)

Висновок розділу: Personal Access Tokens, runner'и Actions, ключі розгортання для кожного репозиторію та пошуковий індекс Bleve завжди потребують ручних дій. Плануйте їх як завдання міграції, а не як щось другорядне.

Перевірте, що міграція пройшла успішно

Почніть з doctor, потім перевірте цифри, а тоді протестуйте те, що користувачі справді роблять. Doctor виявляє проблеми на рівні бази даних; ручні перевірки виявляють втрату даних і проблеми доступу, яких doctor не бачить.

1. Виконайте forgejo doctor check --all --log-file /tmp/doctor.log, потім прочитайте лог, перш ніж вносити зміни. Використайте --fix лише для конкретного виправлення, суть якого ви розумієте.
2. Переконайтеся, що кількість репозиторіїв, кількість issue та PR, а також кількість об'єктів LFS і загальний розмір збігаються з показниками до міграції. Розбіжність тут означає, що щось не перенеслося.
3. Протестуйте push і pull через SSH. Якщо клієнти отримують невідповідність хостового ключа, ви не скопіювали /etc/ssh/ssh_host_* на новий сервер.
4. Увійдіть і переконайтеся, що 2FA працює для облікового запису, який її використовує. Якщо TOTP не працює, дивіться застереження до варіанту A вище.
5. Перегенеруйте Personal Access Tokens, повторно зареєструйте runner'и Actions і запустіть тестовий workflow.

Кілька симптомів після міграції мають відомі причини. Відсутній favicon чи логотип означає, що ваші брендингові файли досі знаходяться в public/assets/img/ замість custom/, де їх тепер очікує Forgejo. Помилки 404 на маршрутах пакетів вказують на неправильно налаштовані шляхи сховища. Помилка Actions «repository not found», це uses: проблема з дзеркалами. Перейдіть на повні URL. Порожня сторінка або сторінка з помилкою 500 після входу на базі даних SQLite означає, що ви нижче мінімуму, який документація з оновлення встановили межу на Forgejo v1.19.3-0.

Коли має сенс залишитися на Gitea

Міграція, це вибір, а не обов'язок. Якщо ви вже перебуваєте за межею і складність міграції переважує вигоду від управління чи функцій для вашої ситуації, залишитися на Gitea, це легітимний вибір. Gitea активно підтримується (кілька релізів на місяць, наразі на v1.26.4), а CommitGo пропонує комерційні варіанти, зокрема Gitea Enterprise, Gitea Cloud і сертифікацію SOC 2 Type 2 для команд, яким вони потрібні.

Варто також чесно зважити занепокоєння щодо проміжної версії з завершеним терміном підтримки (EOL). Підтримуваний прямий шлях вимагає короткочасного встановлення Forgejo v10.0, яка перебуває в статусі EOL з квітня 2025 року. Це прийнятно як тимчасовий крок міграції, від якого ви одразу ж переходите далі, але деякі оператори матимуть заперечення з міркувань політики. Для них міграція через репозиторій/API у свіжий екземпляр Forgejo може повністю уникнути цього кроку з EOL, тоді як розгортання на новому сервері все одно залежить від обраного методу міграції.

Якщо ваша причина переходу, активність розробки, дані підтверджують Forgejo як активніший проєкт: аналіз від honeypot.net нарахували 3 039 комітів Forgejo проти 1 228 комітів Gitea за період з липня 2024 по травень 2025 року, і 232 контриб'ютори Forgejo проти 153 для Gitea за рік, що завершився в травні 2025 року. Це лише один сигнал серед кількох; зважте його проти ризику вашої міграції, а не сприймайте як вирішальний.

Висновок розділу: міграція не обов'язкова. Це рішення про баланс переваг з управління й активності проти ризику міграції, і обидва варіанти виправдані.

Оберіть свій шлях і спочатку зробіть резервну копію

Ваш шлях міграції зводиться до одного числа: версії вашої Gitea. На v1.22 або раніше ви йдете підтримуваним двоетапним шляхом через Forgejo v10. На v1.23 або новіше ви обираєте обхідний шлях за рівнем прийнятної втрати даних: пониження SQL/схеми, скрипти від спільноти, міграція через репозиторій/API або розгортання на новому сервері. Яким би шляхом ви не пішли, спочатку зробіть резервну копію каталогу даних і бази даних, виконайте forgejo doctor після, і переконайтеся, що кількість репозиторіїв, issue та об'єктів LFS збігається з тим, з чого ви починали.

Визначте свою версію, зробіть резервну копію і дотримуйтесь відповідного рядка. Шлях складніший, ніж обіцяли старі туторіали, але він чітко визначений, щойно ви розумієте, де перебуваєте відносно межі версій.

Часті запитання

Чи можна оновитися напряму з Gitea до Forgejo?

Так, якщо у вас Gitea v1.22 або раніше: оновіться напряму до Forgejo v10.0, потім оновіть Forgejo v10 до поточного релізу. Ні, якщо у вас Gitea v1.23 або новіше. Forgejo v10.0 була останнім релізом, що підтримував прозоре пряме оновлення, тож новіші версії Gitea потребують обхідного шляху.

Яка версія Gitea сумісна з Forgejo?

Gitea v1.22 і раніші версії мають підтримуваний прямий шлях оновлення до Forgejo (до Forgejo v10.0, а потім далі до поточної версії). Gitea v1.23 і новіші не мають офіційно підтримуваного прямого шляху, оскільки Forgejo припинив підтримку прозорих оновлень з Gitea v1.23+ у релізах після v10.0.

Чи можна перенести дані з Gitea 1.26 у Forgejo?

Так, але не через підтримуване пряме оновлення. Ваші варіанти: міграція через репозиторій/API, де історія Git надійна частина, а метадані потрібно перевіряти по кожному репозиторію; експериментальний скрипт міграції; або розгортання на новому сервері з використанням одного з непідтримуваних методів для 1.23+ вище. Офіційно підтримуваного шляху на місці з Gitea 1.26 не існує.

Чи переносяться мої Personal Access Tokens?

Плануйте відтворити або оновити Personal Access Tokens після міграції. Деякі шляхи міграції не зберігають їх, а навіть коли токени залишаються, користувачам варто перевірити їхні області дії, перш ніж знову на них покладатися. Будь-які скрипти чи інтеграції, що використовують старі токени, слід протестувати й оновити після переходу.

Чи працюють мої воркфлоу Gitea Actions у Forgejo?

Здебільшого так, з двома обов'язковими виправленнями. Воркфлоу uses: короткі посилання ламаються, бо Forgejo і Gitea тягнуть actions з окремих дзеркал. Замініть їх на повні URL GitHub (наприклад, uses: https://github.com/sammcj/dotenv-output-action@main). Також потрібно повторно зареєструвати ваші Actions runners, оскільки їхні токени реєстрації прив'язані до старого імені хоста.

А як щодо міграції з Gogs на Forgejo?

Це інша міграція з іншим шляхом, і вона поза межами цього матеріалу. Цей посібник охоплює саме перехід з Gitea на Forgejo; для джерела Gogs зверніться до офіційної документації з міграції Forgejo щодо специфічної процедури для Gogs.