GiteaからGitLabへ移行しよう！ — もっとGitLabを使いこなすための第一歩
はじめに
「今使っているソースコード管理システム、なんとなく使い続けているけど、もっと良いものがあるんじゃないか？」
そう思ったことはありませんか？
GiteaはシンプルなセルフホストGitサービスとして人気ですが、GitLabには CI/CD、コードレビュー、Issue管理、セキュリティスキャン など、開発ライフサイクル全体をカバーする機能が揃っています。
この記事では、GiteaからGitLabへの移行手順 を、公式ドキュメント（GitLab 17.8時点）をもとにわかりやすく解説します。移行は思ったよりずっと簡単です。一歩踏み出して、GitLabの世界を体験してみましょう！
移行でできること・できないこと
まず、Giteaインポーターが対応しているアイテムを確認しましょう。
| Gitea上のデータ | インポート対応 |
|---|---|
| リポジトリの説明 | 対応 |
| Gitリポジトリデータ | 対応 |
| Issues | 対応 |
| プルリクエスト | 対応 |
| マイルストーン | 対応 |
| ラベル | 対応 |
| プルリクエストのDiffノート | 非対応 |
主要なデータはほぼ移行できます。Diffノート（レビューコメント）は現時点では非対応のため、必要に応じて手動での移行を検討してください。
バージョン要件・前提条件
移行を始める前に、以下を確認してください。
- Gitea 1.0.0 以降 が必要です
- GitLabで Giteaインポートソース が有効になっていること
- GitLab.comでは デフォルトで有効
- セルフマネージドの場合は管理者に確認またはご自身で設定が必要
- 設定場所：
管理エリア > 設定 > インポートとエクスポートの設定
- 設定場所：
- インポート先のグループまたはネームスペースで Maintainer または Owner ロール が必要（GitLab 16.0以降）
バージョン別の重要な変更点
| GitLabバージョン | 変更内容 |
|---|---|
| 15.8 | 存在しないネームスペース・グループの自動作成が廃止。個人ネームスペースへのフォールバックも廃止 |
| 16.0 / 15.11.1 / 15.10.5 | インポートに必要なロールがDeveloperからMaintainerに変更 |
| 16.11 | パスに . を含むプロジェクトのインポートが可能に |
| 17.2 | 一部のインポートアイテムに「Imported」バッジが表示されるように |
| 17.8 | GitLab.comおよびGitLab Self-Managed で、移行後のユーザーコントリビューション・メンバーシップマッピング機能が有効化 |
移行手順：ステップバイステップ
ステップ1：GitLabで新規プロジェクトを作成する
- GitLabの右上にある 「新規作成」 から 「新規プロジェクト/リポジトリ」 を選択
- 「Gitea」 を選択してインポート認証フローを開始
ステップ2：GiteaでPersonal Access Tokenを発行する
GiteaはOAuthプロバイダーではないため、アクセストークンを使って認証を行います。
- Giteaのインスタンスで以下のURLにアクセス
https://your-gitea-instance/user/settings/applications - 「Generate New Token」 を選択
- トークンの説明を入力
- 「Generate Token」 をクリック
- 表示されたトークンハッシュをコピー（このタイミングしか表示されません）
ステップ3：GitLabにトークンを入力してリポジトリを一覧表示
- GitLabに戻り、コピーしたトークンをGiteaインポーターに貼り付け
- 「List your Gitea repositories」 をクリック
- GitLabがリポジトリ情報を読み込むまで待機
読み込みが完了すると、インポーター画面にリポジトリの一覧が表示されます。
ステップ4：インポートするリポジトリを選択して実行
各リポジトリには以下のステータスが表示されます：
- インポート中：処理開始済み
- 完了（緑）：インポート済み
- 「Import」ボタン：未インポート
- 「Re-import」ボタン：インポート済み（再インポート可能）
インポートの方法は3通りあります：
- すべて一括インポート：左上の「Import all projects」を選択
- 選択してインポート：プロジェクト名でフィルタリングし、対象のみ選択
- 名前・ネームスペースを変更してインポート：権限があれば、インポート時にプロジェクト名や格納先を変更可能
プライバシー設定について
Giteaでprivateに設定されているリポジトリは、GitLabでもprivateとして作成されます。公開設定はそのまま引き継がれるので、意図せず公開されてしまう心配はありません。
「Imported」バッジについて（GitLab 17.2以降）
インポートされたIssue・マージリクエスト・コメント（IssueやMRへの返信）には 「Imported」バッジ が表示されます。「なぜバッジが付いているんだろう？」と疑問に思うことがあるかもしれませんが、これはインポートされたアイテムであることを示すものです。
ユーザーコントリビューションのマッピングについて
GiteaはOAuthプロバイダーではないため、Gitea上のユーザーとGitLab上のユーザーの自動マッピングはできません。
そのため、デフォルトでは インポートを実行したユーザー（プロジェクト作成者） がコントリビューターとして設定されます。ただし、Issueについては元のGitea作者名を確認できます。
移行後マッピング（GitLab 17.8以降）
GitLab 17.8より、GitLab.comおよびGitLab Self-Managed の両方で「移行後ユーザーコントリビューション・メンバーシップマッピング」機能が利用可能になりました。インポート完了後に、コントリビューションを適切なユーザーに紐づける作業が行えます。
詳細は公式ドキュメントの post-migration user contribution and membership mapping を参照してください。
代替マッピング方法（GitLab 18.5以前のみ）
GitLab 18.5以前では、gitea_user_mapping フィーチャーフラグを無効化することで代替マッピング方法を使えます。ただし、この方法には以下の制限があります：
- GitLab.comおよびGitLab 18.6以降のSelf-Managed / Dedicated では利用不可
- 発見された問題は修正される予定がない
特別な理由がない限り、移行後マッピング（post-migration method）の利用を推奨します。
移行後に試してほしいGitLabの機能
せっかくGitLabに移ってきたなら、ぜひ以下の機能を活用してみてください！
CI/CDパイプライン (GitLab CI/CD)
.gitlab-ci.yml を置くだけで、ビルド・テスト・デプロイを自動化できます。GitHub Actionsと似た感覚で使えます。
マージリクエスト (Merge Request)
GitHubのPull Requestに相当する機能です。コードレビューはもちろん、承認ルールの設定や自動マージも可能です。
イシューボードとマイルストーン
カンバンスタイルのイシューボードで、チームのタスク管理が一元化できます。
セキュリティスキャン (GitLab Ultimate)
SAST（静的解析）やDependency Scanningなど、セキュリティ機能も充実しています。
まとめ
| 項目 | 内容 |
|---|---|
| 必要なGiteaバージョン | 1.0.0以降 |
| 必要なGitLabロール | Maintainerまたはオーナー（16.0以降） |
| ユーザーマッピング | 移行後マッピングを推奨（17.8以降） |
| 主な非対応データ | プルリクエストのDiffノート |
GiteaからGitLabへの移行は、思ったよりずっとスムーズに行えます。まずは1つのリポジトリを試しにインポートしてみて、GitLabの豊富な機能を肌で感じてみてください。
開発体験がきっと変わるはずです。GitLabを使いこなして、チームの生産性を一段階上げていきましょう！