Skip to main content

GitLab から GitHub への移行を計画する

タイムライン、移行されるデータ、組織の構造を理解して、移行を計画します。

移行する必要がある量を決定する

あなたのアプローチを大きく形作るので、最初にあなたのタイムラインを見つけ出してください。 タイムラインを決定するための最初の手順は、移行する必要があるもののインベントリを取得することです。

  • リポジトリの数 (プロジェクト)
  • マージ要求の数

メモ

移行のタイミングは、主にリポジトリ内のマージ要求の数に基づいています。 1,000 個のリポジトリを移行する必要があり、各リポジトリに平均で 100 個のマージ要求がある場合は、移行が非常に迅速になる可能性があります。 100 個のリポジトリのみを移行するが、リポジトリごとに平均で 75,000 個のマージ要求がある場合、移行にははるかに時間がかかり、より多くの計画とテストが必要になります。

inventory-report の GL2GH extension of the GitHub CLI コマンドをお勧めします。 このコマンドは GitLab API に接続し、2 つの CSV ファイルを作成します。 groups.csv には GitLab グループが一覧表示され、 projects.csv にはマージ要求の数を含むプロジェクトが一覧表示されます。

CSV ファイルを生成するには、次のコマンドを使用して、 GITLAB_SERVER_URL を GitLab サーバーの URL ( https://gitlab.com など) に置き換え、報告するグループに YOUR_GITLAB_GROUP します。 アクセスできるすべてのプロジェクトを報告するには、 --gitlab-groupを省略します。 使用可能なすべてのオプションについては、 gh gl2gh inventory-report --helpを実行します。

Shell
gh gl2gh inventory-report --gitlab-server-url GITLAB_SERVER_URL --gitlab-group YOUR_GITLAB_GROUP

移行する必要があるリポジトリのインベントリを取得したら、インベントリ データを目的のタイムラインと比較します。

  • 組織がより高度な変更に耐えられる場合、すべてのリポジトリを一度に移行して、移行作業を数日で完了できる可能性があります。
  • 同時に移行できないチームがある場合は、チームのタイムラインに合わせて移行をバッチ処理して調整し、移行作業を拡張することができます。

組織構造 GitHub 決定する

次に、 GitHubで作成する組織構造を計画します。 GitLab と GitHub には、企業の作業を整理するさまざまな方法があります。

  • GitLab: インスタンス > グループ>サブグループ (深さ 20 レベルまで入れ子にできる) > プロジェクト (リポジトリ)
  • GitHub: エンタープライズ >組織> リポジトリ

GitHubに移行した後は、1 つのエンタープライズ アカウントと、その企業が所有する多数の組織のみを持つ必要があります。 GitLab の各最上位グループは、通常、 GitHub上の 1 つの組織に対応します。 作成する組織の数に関するガイダンスについては、 企業で作業を整理するためのベスト プラクティス を参照してください。

メモ

GitHub は、GitLab の入れ子になったサブグループと同等のサブグループを持っていません。 各サブグループの GitHub に組織を作成することはお勧めしません。これにより、各組織内のグループ化されていないリポジトリのリストが大きくなる可能性があるためです。 代わりに、チームを作成することで、リポジトリのグループへのアクセスを管理できます。

移行作業をバッチに分割する場合は、新しい構造を使用してそれらを特定できます。 GitLab に複数のグループがあり、各グループのリポジトリが妥当なサイズのバッチである場合は、グループごとのバッチ処理を検討してください。

  1. 新しい組織構造を決定します。
  2. 移行作業を小さいバッチに分割する必要があるかどうかを決めます。
  3. そうする場合は、移行の分割方法を決めます。

リポジトリのアクセス許可の構成

アクセス許可は、 GitHub では GitLab とは動作が異なるため、 GitHub Enterprise Importer はリポジトリのアクセス許可、グループ設定、またはグループ メンバーシップを GitLab から移行しません。

GitLab では、メンバーにはグループ、サブグループ、またはプロジェクト レベルでロール (ゲスト、レポーター、開発者、保守者、所有者など) が付与され、これらのロールは階層の下に継承されます。 これらのロールは GitHubに直接マップされないため、移行後にアクセスを再作成する必要があります。

GitHubで移行されたリポジトリへのアクセス権をユーザーに付与するには、チームを作成し、各チームに関連する組織とリポジトリへの適切なレベルのアクセス権を付与することをお勧めします。 その後、それらのチームにユーザーを追加できます。 「Enterprise 内の Teams」を参照してください。