GiteaからForgejoへ移行する：サポートされるパスとGitea 1.23以降向けの解決策

Q: GiteaのActionsワークフローはForgejoで動作しますか。

ほとんどの場合は動作しますが、2つの必須の修正が必要です。ワークフロー uses: のような短い参照は、ForgejoとGiteaがそれぞれ別のミラーからアクションを取得するため機能しなくなります。完全なGitHubのURL(例えば uses: https://github.com/sammcj/dotenv-output-action@main ）。登録トークンが旧ホスト名に紐づいているため、Actionsランナーの再登録も必要です。

Giteaを停止し、Forgejoをインストールし、app.iniとデータディレクトリをコピーして、どの移行ガイドにも書かれている通りの方法でサービスを起動します。Web UIは立ち上がります。ところが、データベースの移行に失敗するか、さらに悪いことに、スキーマのバージョンが新しすぎて理解できないという理由でForgejoが起動を拒否します。あなたはGitea 1.23以降を使用しており、誰もが説明しているシンプルなその場でのアップグレードはもはや当てはまりません。

Forgejoは2024年初頭にGiteaからハードフォークし、以来両プロジェクトはデータベーススキーマのレベルで分岐してきました。GiteaからForgejoへどう移行するかは、今やあなたのGiteaのバージョンに完全に依存します。このガイドでは、あなたのバージョンに応じた正確なパス、ネイティブインストールとDockerインストール両方の完全なコマンド、Gitea 1.23以降向けの回避策、そして検証チェックリストを示し、リポジトリ、issue、ユーザーを失うことなく移行できるようにします。

要約

バージョンの崖は実際に存在します。 Forgejo v10.0は、Giteaからの透過的な直接アップグレードをサポートする最後のリリースでした。Gitea v1.22は、サポートされる直接パスを利用できる最も新しいバージョンです。
Gitea v1.22以前の場合。 まずForgejo v10.0.xに移行し、その後Forgejo v10を現行リリース(v15)にアップグレードします。2段階の経路で、いずれも公式サポートされています。
Gitea v1.23以降の場合。 公式サポートされている直接移行の経路は存在しません。SQL/スキーマのダウングレード、コミュニティ提供の移行スクリプト、リポジトリ / API移行、あるいはこれらのいずれかの方法を使った新規サーバーへのステージング移行の中から選ぶことになります。それぞれ異なるデータ損失のトレードオフを伴います。
何かを操作する前に、データディレクトリとデータベースをバックアップしてください。 以下のパスはいずれも、復元可能なバックアップがあることを前提としています。サポート対象外のパスでは、その前提が二重に重要になります。
以下のものは、移行後に必ず対応が必要です Personal Access Tokensの再作成または監査、Actionsランナーの再登録、そしてBleve検索インデックスの削除と再構築を計画してください。どの経路を選んでも、これらは必ず計画に組み込んでおいてください。
移行は必須ではありません。 Giteaは積極的にメンテナンスされています。あなたの状況において移行のリスクがメリットを上回るなら、「Giteaにとどまる」という判断は理にかなっています。

本稿の対象外: Gogs、GitHub、GitLabからForgejoへの移行、およびForgejo Actionsをゼロから構築すること。

前提条件 / 必要なもの

コマンドを1つでも実行する前に、Giteaのデータディレクトリ（デフォルトのネイティブインストールでは/var/lib/gitea）とデータベースという2つのものについて、完全で復元可能なバックアップがあることを確認してください。データベースが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は2025年4月16日以降EOLとなっています。これは移行期間中のみインストールするもので、直後にそこからアップグレードして離れます。

直接アップグレードの経路が壊れた理由

2024年12月、Forgejoプロジェクトは互換性に関する声明がはっきりと線引きをしました。「今後のForgejoのバージョンは、v1.23以降を実行しているGiteaインスタンスからのアップグレードをサポートしません」。この一文に、問題のすべてが凝縮されています。

2024年初頭にForgejoがGiteaからフォークして以降、両者のコードベースは分岐を続け、データベースのスキーマも次第に乖離していきました。Forgejoは既存のGitea運用者が移行できるよう互換性の期間を設けていましたが、その期間には終わりがありました。2025年1月16日にリリースされたForgejo v10.0は、 "the last version to allow a transparent upgrade from Gitea v1.22 or lower." v10.0より新しいバージョンは、Giteaのデータベースを直接読み込むことができません。

多くの人がつまずくのはタイミングの問題です。Gitea v1.23は2024年後半にリリースされましたが、 2026年6月時点の現行Giteaリリースはv1.26.4です。Giteaのインスタンスをある程度最新に保っていた場合、あなたはすでに崖を越えており、標準的なチュートリアルはもはやあなたの状況を説明していません。

このセクションの要点: 公式サポートされている直接移行の経路は、Gitea v1.22までしか対応していません。それより新しいバージョンはすべて追加の手順が必要です。

Giteaのバージョン別に移行パスを見つける

実行する gitea --version、該当する行を見つけて、3列目のパスに従ってください。このガイドの残りの部分は、これらの行の背後にある詳細です。

Giteaのバージョン	公式サポートされているForgejoへの移行先(直接)	移行パス
1.21以下	Forgejo v7.0～v10.0	Forgejo v10.0.xに切り替えてから、現行バージョン(v15)にアップグレードする
1.22	Forgejo v8.0～v10.0	Forgejo v10.0.xに切り替えてから、現行バージョン(v15)にアップグレードする
1.23	なし（非サポート）	SQLバージョンパッチ(オプションA)を適用してから、公式サポートされている手順に進む
1.24～1.25.2	なし（非サポート）	連続SQLダウングレードスクリプト(オプションB)を実行してから、公式サポートされている手順に進む
1.26+	なし（非サポート）	実験的なスクリプト、またはリポジトリ単位のAPI移行（オプションC）

バージョン互換性に関する記述は、次から直接引用しています Forgejoの公式互換性発表：v1.21までのGiteaはForgejo v7.0からv10.0へ移行でき、Gitea v1.22はForgejo v8.0からv10.0へ移行できます。どちらもサポートされる直接移行先としてはv10.0が上限です。

バージョンの問題の背後には3つの移行戦略があり、具体的な手順を見る前にこれらを把握しておくと役立ちます

同じサーバー上でのその場での移行。 既存のサーバー上でバイナリまたはコンテナイメージを入れ替えます。お使いのバージョンが対応していれば最も手間が少なく、v10.0を中間バージョンとして経由する必要があります。
新規サーバーでのステージング。 新しいサーバーを用意し、Giteaのバージョンに合った移行方法の安全な移行先として使います。これにより元のGiteaサーバーを保護でき、ロールバックも容易になりますが、Gitea 1.23以降のデータベーススキーマの問題そのものを回避できるわけではありません。
リポジトリ / APIによる移行。 Forgejoの移行ツールを使って、古いGiteaインスタンスからリポジトリを取り込みます。Gitの履歴は確実に移行できる部分ですが、イシュー、PR、ラベル、リリース、wikiデータ、コメントといったメタデータはベストエフォートとして扱い、リポジトリごとに確認してください。

Decision flow showing the Gitea to Forgejo migration path: Gitea v1.22 or earlier takes the supported path through Forgejo v10 to current Forgejo, while Gitea 1.23+ requires a workaround such as a SQL downgrade, community script, or repo and API migration before cutover.

公式サポートされている移行経路: Gitea v1.22以前

Gitea v1.22以前を使っている場合、公式移行ドキュメント 2段階の経路を説明しています。まずForgejo v10.0.xに移行し、その後Forgejo v10を現行リリースにアップグレードするというものです。Forgejo v10.xはGitea v1.22のデータベースをそのまま読み込めるため、最初の段階はそのまま置き換えるだけで済み、2番目の段階は通常のForgejoアップグレードです。

サーバー上でのGiteaの動作方法に応じて、2つの方法があります。既存のセットアップに合った方を選んでください。Giteaがシステムサービスとして動作している場合はネイティブの経路を、Giteaがコンテナ内で動作している場合はDockerの経路を使用してください。Forgejo v10.xは、Gitea v1.22.xのそのまま置き換え可能な代替として機能します。

ネイティブ（systemd）パス

まずバックアップを取ってください。次に、ディストリビューションのパッケージ、またはv10.0に固定したリリースバイナリを使ってForgejo v10.0.xをインストールします。何かをコピーする前に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

次に、バイナリを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が重大なエラーを報告せず、web UIにリポジトリが表示されれば、最初の移行は完了です。

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コンテナの場合、データはrootlessイメージの実行ユーザーに合わせて、ユーザー1000、グループ1000が所有している必要があります。コンテナがv10.xで起動した後、同じ forgejo doctor check --all をコンテナ内から実行し、その後イメージタグを現行のv15リリースにアップグレードして再起動してください。

Gitea v1.23以降を使っている場合

Four workarounds for migrating Gitea 1.23 and newer to Forgejo: SQL schema downgrade for narrow 1.23 cases, community scripts for 1.24 to 1.25.2, repo and API migration, and fresh-server staging, each with a documented risk level.

標準的なガイドの説明はここで終わりますが、現在多くの実運用環境がまさにこの状況にあります。Gitea v1.23以降からの公式サポートされた直接移行の経路は存在しないため、以下の選択肢はすべてコミュニティ由来のものか、何らかのデータ損失を伴うものです。どれを実行する前にも、データディレクトリとデータベースの完全なバックアップを取り、復元できることを確認してください。これらの方法は本番データを変更するため、バックアップだけが唯一の元に戻す手段です。

この3つのオプションは、リスクの大きさとデータをどれだけ保持できるかという点で異なります。受け入れられるトレードオフのものを選んでください。

オプション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を直接設定すると、TOTPシークレットのエンコード方式を変更した304→305の移行処理がスキップされてしまいます。 Codeberg issue #8210 は、これが影響を受けるユーザーの二要素認証を破損させると記載しています。対処法は、バージョンを304に設定して移行を実行させるか、two_factorテーブルの行を削除してユーザーに再登録させることです。TOTPを使用しているアカウントが1つでもある場合は、この手順を絶対に飛ばさないでください。

オプション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のデータを最も確実に保持できます。移行元、権限設定、移行方法によっては、イシュー、プルリクエスト、ラベル、マイルストーン、リリース、wikiデータ、コメントといった付随的なメタデータも移行できる場合がありますが、これらはあくまでベストエフォートとして扱い、リポジトリごとに確認してください。コードのみをアーカイブする用途であれば通常は問題ありませんが、イシュートラッカーがチームの記憶そのものであるようなサーバーの場合は、この経路を選ぶ前にメタデータの移行をテストしてください。

2つの実験的ツールが1.23以降向けにより完全な移行を試みていますが、それぞれ独自の欠点を抱えています。 pacnpal/gitea2forgejo (GitHub）は完全なダンプとAPI同期を行い、暗号化されたフィールドを移行するには一致するSECRET_KEYが必要ですが、Personal Access Tokens、Actionsランナー、webhookコールバックURL、2FAは移行しません。 nicoverbruggen/gitea-to-forgejo (GitHub）はPodmanベースの実験的なツールで、ユーザー、キー、組織、リポジトリ、issue、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の崖の前にいるか後にいるかによって変わります。

何が移行され、何を自分でやり直す必要があるか

Checklist of what transfers automatically in a Gitea to Forgejo migration, including users, repositories, issues, PRs, LFS objects, and SSH public keys, versus what must be manually verified or recreated, including Personal Access Tokens, Actions runners, the Bleve search index, SSH host keys, 2FA, and webhooks.

データの一部は自動的に移行され、一部は特定の条件を満たした場合にのみ移行され、一部は決して移行されず手作業での再作成が必要です。どれがどれに当たるかを開始前に把握しておくかどうかが、スムーズな切り替えと、混乱したユーザーへの1週間の対応との分かれ目になります。

項目	移行されるか?	条件
ユーザーアカウントとパスワード	あり	自動
ユーザーのSSH公開鍵	あり	自動
SSHホストキー(サーバーの識別情報)	いいえ（手動）	/etc/ssh/ssh_host_*をコピーしないと、すべてのクライアントでホストキーの不一致が発生します
リポジトリとgitの履歴	あり	データディレクトリのコピーによる方法
Issue、PR、ラベル、マイルストーン、コメント	あり	データベース経由
LFSオブジェクト	あり	オブジェクト数と合計サイズが一致することを確認する
Webhook(設定)	あり	配信履歴は移行されません
CI/CDのシークレット	条件付き	SECRET_KEYが一致する場合のみ有効で、それ以外は何も警告なく読み取り不能になります
OAuthアプリ	条件付き	SECRET_KEYが一致する場合のみ。コールバックURLの更新が必要になることがあります
2FA（TOTPシード）	条件付き	SECRET_KEYが一致する場合のみ
Personal Access Tokens	再作成 / 監査の計画を立てる	移行後の最も安全な運用方法であり、古いトークンに頼る前に検証すること
Actionsランナーの登録	いいえ（再登録が必要）	登録トークンはホスト名に紐づいています
Actionsの実行履歴・ログ	No	どのパスでも移行されません
Bleve検索インデックス	いいえ（削除して再構築）	/var/lib/gitea/data/indexers/を削除し、再生成させます
カスタムブランディング・テンプレート	はい(ファイル)	public/assets/img/は、現在ではcustom/内に置く必要があります
リポジトリごとのデプロイキー	いいえ（手動で再追加）	どのパスでも移行されません

静かに壊れる、あるいはすべてのユーザーに影響するために特に大きな打撃を与える項目が4つあるため、意図的に対処してください。ユーザーはPersonal Access Tokensを再作成または監査すべきです。新しいホスト名に対してActionsランナーを再登録する必要があります。ForgejoがBleve検索インデックスをきれいに再構築できるよう削除する必要があります。そして、次の uses: のような短い参照を、Actionsワークフロー内で完全なGitHubのURLに切り替えてください。ForgejoとGiteaはそれぞれ別のミラーからアクションを取得するため、相対参照は誤った場所を指してしまいます。

プロのヒント: 移行中にGiteaとForgejoを並行稼働させ、両方が同じRedisインスタンスを参照している場合は、開始前にForgejo側をRedisのdb=1に変更してください。両方ともデフォルトはdb=0であり、これを共有するとGiteaがForgejoの移行イベントを消費してしまい、移行キューが壊れます。(blog.mei-home.net documents this exact failure.)

このセクションの要点: Personal Access Tokens、Actionsランナー、リポジトリごとのデプロイキー、Bleve検索インデックスは常に手作業での対応が必要です。後回しにせず、移行タスクとしてあらかじめ計画に組み込んでください。

移行が成功したことを確認する

まず診断コマンドを実行し、次に各種の数値を確認し、最後にユーザーが実際に行う操作をテストしてください。診断コマンドはデータベースレベルの問題を検出しますが、データ損失やアクセスの問題は診断コマンドでは見つけられないため、手動での確認が必要です。

実行する forgejo doctor check --all --log-file /tmp/doctor.log、変更を加える前にログを確認してください。 --fix 自分が理解している特定の修復のためだけに使用してください。
リポジトリ数、issueとPRの数、LFSオブジェクト数と合計サイズが、移行前の数値とすべて一致していることを確認してください。ここで不一致があれば、何かが正しく移行されなかったことを意味します。
SSHでのpushとpullをテストしてください。クライアント側でホストキーの不一致が発生する場合は、/etc/ssh/ssh_host_*を新しいサーバーにコピーできていません。
ログインして、2FAを利用しているアカウントで正しく機能することを確認してください。TOTPが壊れている場合は、上記のオプションAの注意点を参照してください。
Personal Access Tokensを再生成し、Actionsランナーを再登録して、テスト用のワークフローを実行する。

移行後に見られるいくつかの症状には既知の原因があります。faviconやロゴが表示されない場合は、ブランディング用アセットがForgejoの想定するcustom/ではなく、public/assets/img/にまだ置かれたままであることを意味します。パッケージルートでの404エラーは、ストレージパスの設定ミスを示しています。「repository not found」でActionsが失敗するのは、 uses: のミラーの問題です。完全なURLに切り替えてください。SQLiteデータベースでログイン後に空白または500エラーのページが表示される場合は、最小要件を満たしていないことを意味し、これはアップグレードドキュメントは、Forgejoをv1.19.3-0としています。

Giteaにとどまることが理にかなう場合

移行は義務ではなく、選択です。すでに崖を越えていて、あなたの状況において移行の複雑さがガバナンスや機能上のメリットを上回るなら、Giteaにとどまることも正当な選択です。Giteaは積極的にメンテナンスされており（月に複数回のリリース、現在v1.26.4）、CommitGoは次のような商用オプションも提供しています。 Gitea Enterprise、Gitea Cloud、SOC 2 Type 2認証それらを必要とするチーム向けに。

EOL(サポート終了)状態の中間バージョンを経由することについても、正直に検討すべき懸念です。公式サポートされている直接移行の経路では、2025年4月にEOLを迎えたForgejo v10.0を一時的にインストールする必要があります。すぐにアップグレードして通過するだけの一時的な移行手順としては許容範囲ですが、方針上これに反対する運用担当者もいるでしょう。そうした場合は、新規のForgejoインスタンスへのリポジトリ / API移行を使えばEOLの中間バージョンを完全に回避できますが、新規サーバーへのステージング移行は、結局選んだ移行方法に依存します。

移行する理由が開発の活発さであるなら、データはForgejoの方がより活発なプロジェクトであることを裏付けています。 honeypot.net 2024年7月から2025年5月までの間に、Forgejoのコミット数は3,039件、Giteaは1,228件、そして2025年5月までの1年間で、Forgejoの貢献者数は232人、Giteaは153人と集計しています。これは複数ある判断材料の1つに過ぎず、決定的なものとして扱うのではなく、移行リスクと天秤にかけて考えるべきです。

このセクションの要点: 移行は必須ではありません。この判断は、ガバナンスと開発の活発さに対する好みと、移行リスクとを天秤にかけるものであり、どちらを選んでも妥当な選択です。

移行方法を選び、まずバックアップを取る

移行方法は、突き詰めればGiteaのバージョンという1つの数字にかかっています。v1.22以前であれば、Forgejo v10を経由する公式サポートの2段階の経路を取ります。v1.23以降であれば、許容できるデータ損失に応じて回避策を選びます。SQL/スキーマのダウングレード、コミュニティ提供のスクリプト、リポジトリ / API移行、あるいは新規サーバーへのステージング移行です。どの経路を選ぶにせよ、まずデータディレクトリとデータベースをバックアップし、次を実行してください forgejo doctor 実行後、リポジトリ数、イシュー数、LFSの件数が移行前と一致していることを確認してください。

自分のバージョンを特定し、バックアップを取り、該当する行に従ってください。このパスは以前のチュートリアルが約束していたよりも手間がかかりますが、バージョンの崖のどちら側にいるかさえ分かれば、道筋ははっきりしています。

よくある質問

GiteaからForgejoへ直接アップグレードできますか。

Gitea v1.22以前を使用している場合は、はい。まずForgejo v10.0に直接アップグレードし、その後Forgejo v10を現行リリースにアップグレードしてください。Gitea v1.23以降を使用している場合は、いいえです。Forgejo v10.0が、透過的な直接アップグレードをサポートする最後のリリースだったため、それより新しいGiteaのバージョンでは回避策が必要になります。

Forgejoと互換性のあるGiteaのバージョンは?

Gitea v1.22以前には、Forgejoへのサポートされた直接アップグレードパスがあります（Forgejo v10.0まで、その後現行版へ進みます）。Gitea v1.23以降には公式にサポートされる直接パスはありません。Forgejoがv10.0以降のリリースで、Gitea v1.23以降からの透過的なアップグレードのサポートを打ち切ったためです。

Gitea 1.26からForgejoへ移行できますか。

はい、ただし公式サポートされている直接アップグレードによるものではありません。選択肢としては、Gitの履歴は確実だがメタデータはリポジトリごとにテストが必要なリポジトリ / API移行、実験的な移行スクリプト、あるいは上記の非公式な1.23以降向けの方法のいずれかを使った新規サーバーへのステージング移行があります。Gitea 1.26からの公式サポートされたその場でのアップグレード経路は存在しません。

Personal Access Tokensは移行されますか。

移行後にPersonal Access Tokensを再作成またはローテーションする計画を立ててください。移行方法によってはトークンが引き継がれず、たとえトークン自体が残っていても、再び使う前にスコープを監査すべきです。古いトークンを使うスクリプトや連携は、切り替え後にテストと更新が必要です。

GiteaのActionsワークフローはForgejoで動作しますか。

ほとんどの場合は動作しますが、2つの必須の修正が必要です。ワークフロー uses: のような短い参照は、ForgejoとGiteaがそれぞれ別のミラーからアクションを取得するため機能しなくなります。完全なGitHubのURL(例えば uses: https://github.com/sammcj/dotenv-output-action@main）。登録トークンが旧ホスト名に紐づいているため、Actionsランナーの再登録も必要です。

GogsからForgejoへの移行についてはどうか

それは異なる移行経路を持つ別の移行であり、本稿の対象外です。本ガイドはGiteaからForgejoへの移行に特化しており、Gogsが移行元の場合は、Gogs向けの手順についてForgejoの公式移行ドキュメントを参照してください。

リポジトリを壊さずにGiteaからForgejoへ移行する方法

要約