Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-09-25. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

GitHub.com から GitHub Enterprise Cloud へのリポジトリの移行

GitHub CLI または GraphQL API を使って、GitHub.com から GitHub Enterprise Cloud に Organization を移行できます。

Tool navigation

GitHub Enterprise Importer

を使った Organization の移行について

GitHub Enterprise Cloud への移行には、GitHub.com のアカウント間での移行のほか、データ所在地が を採用している場合はエンタープライズの GHE.com のサブドメインへの移行も含まれます。

GitHub CLI または API を使って、移行を実行できます。

GitHub CLI を使うと移行プロセスが簡単になるので、ほとんどのお客様に推奨されます。 カスタマイズのニーズが高い熟練したお客様は、API を使って、GitHub Enterprise Importer との独自の統合を構築できます。

API の使い方を確認するには、ページの上部にあるツール スイッチャーを使います。
GitHub CLI の使い方を確認するには、ページの上部にあるツール スイッチャーを使います。

前提条件

  • 移行の試験的実行を行い、そのすぐ後で運用環境の移行を完了することを強くお勧めします。 試験的実行について詳しくは、「GitHub 製品間の移行に関する概要」をご覧ください。
  • 移行されるデータと、Importer の既知のサポート制限事項を理解していることを確認します。 詳しくは、「GitHub 製品間の移行について」をご覧ください。
  • 必須ではありませんが、運用環境の移行の間は作業を停止することをお勧めします。 Importer は差分移行をサポートしていないため、移行中に発生した変更は移行されません。 運用環境の移行の間に作業を停止しない場合は、これらの変更を手動で移行する必要があります。
  • 移行元の Organization に関して、Organization 所有者であるか、移行者ロールが付与されている必要があります。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
  • 移行先 Enterprise アカウントに関して、Enterprise 所有者である必要があります。

手順 0: GitHub GraphQL API を使う準備をする

GraphQL クエリを作成するには、独自のスクリプトを記述するか、Insomnia などの HTTP クライアントを使う必要があります。

認証方法など、GitHub GraphQL API での作業の始め方について詳しくは、「GraphQLでの呼び出しの作成」をご覧ください。

すべての GraphQL クエリを、移行に送信します。 データ所在地付き GitHub Enterprise Cloud に移行する場合は、GHE.com のエンタープライズのサブドメインのエンドポイントにクエリを送信してください。

手順 1: 移行先の Enterprise ID を取得する

GitHub.com の Enterprise 所有者として、次のクエリを使用して、移行された Organization を所有する Enterprise アカウントの ID を返します。 Enterprise ID は、移行先を識別するために必要です。

query(
  $slug: String!
){
  enterprise (slug: $slug)
  {
    slug
    id
  }
}
クエリ変数説明
slugEnterprise アカウントのスラッグ。エンタープライズの URL (https://github.com/enterprises/SLUG または https://SLUG.ghe.com) を調べることで識別できます。

手順 2: Organization の移行を開始する

移行を始めると、1 つの Organization とそれに付随するデータが、指定した移行先 Enterprise 内の新しい Organization に移行されます。

mutation startOrganizationMigration (
  $sourceOrgUrl: URI!,
  $targetOrgName: String!,
  $targetEnterpriseId: ID!,
  $sourceAccessToken: String!,
    $targetAccessToken: String!
){
  startOrganizationMigration( input: {
    sourceOrgUrl: $sourceOrgUrl,
    targetOrgName: $targetOrgName,
    targetEnterpriseId: $targetEnterpriseId,
    sourceAccessToken: $sourceAccessToken,
        targetAccessToken: $targetAccessToken
  }) {
    orgMigration {
      id
    }
  }
}
クエリ変数説明
sourceOrgUrl移行元 Organization の URL (例: https://github.com/octo-org)。
targetOrgName新しい Organization に付ける名前。 移行先プラットフォーム上の別の organization で共有することはできません。
targetEnterpriseId手順 2 で返された、新しい Organization の作成先となる Enterprise の ID。
sourceAccessToken移行元 Organization の personal access token (classic)。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。
targetAccessToken移行先 Enterprise の personal access token (classic)。

次のステップでは、startOrganizationMigration ミューテーションから返された移行 ID を使って、移行の状態を調べます。

手順 3: 移行の状態を確認する

移行エラーを検出し、移行が行われていることを確認するには、getMigration クエリを使用して、作成した (複数の) OrganizationMigration のクエリを実行することで、移行の状態を確認できます。

このクエリにより、移行が queuedin progressfailedcompleted のいずれであるかがわかる状態と、移行を待機しているリポジトリの数に関する情報が返されます。 移行が失敗した場合、Importer によってエラーの原因が示されます。

query (
  $id: ID!
){
  node( id: $id ) {
    ... on OrganizationMigration {
      id
            sourceOrgUrl
            targetOrgName
      state
      failure_reason
      remaining_repositories_count
      total_repositories_count
    }
  }
}
クエリ変数説明
id移行の id

手順 1: GEI extension of the GitHub CLI

をインストールする

これが初めての移行の場合は、GEI extension of the GitHub CLI をインストールする必要があります。 GitHub CLI について詳しくは、「GitHub CLI について」をご覧ください。

  1. GitHub CLI をインストールします。 GitHub CLI のインストール手順については、GitHub CLI リポジトリを参照してください。

    注: GitHub CLI のバージョン 2.4.0 以降が必要です。 gh --version コマンドを使って、インストールされているバージョンを確認できます。

  2. GEI extension をインストールします。

    Shell
    gh extension install github/gh-gei
    

GEI extension に関するヘルプが必要なときはいつでも、コマンドで --help フラグを使用できます。 たとえば、gh gei --help とすると使用可能なすべてのコマンドの一覧が表示され、gh gei migrate-repo --help とすると migrate-repo コマンドで使用できるすべてのオプションの一覧が表示されます。

手順 2: GEI extension of the GitHub CLI

を更新する

GEI extension は毎週更新されます。 最新バージョンを確実に使うため、拡張機能を更新してください。

gh extension upgrade github/gh-gei

手順 3: 環境変数を設定する

GEI extension を使って GitHub Enterprise Cloud に移行するには、その前に、移行元の Organization と移行先の Organization にアクセスできる personal access tokens (classic) を作成してから、personal access tokens (classic) を環境変数として設定する必要があります。

  1. Organization 移行のために移行元 Organization を認証するすべての要件を満たす personal access token を作成し、記録します。 詳しくは、「GitHub 製品間の移行のためのアクセスの管理」を参照してください。

  2. Organization 移行のために移行先 Enterprise を認証するすべての要件を満たす personal access token (classic) を作成し、記録します。

  3. personal access tokens (classic) に対する環境変数を設定します。次のコマンドの TOKEN は、上で記録した personal access tokens (classic) に置き換えます。 移行先の Enterprise には GH_PAT を使い、移行元の Organization には GH_SOURCE_PAT を使います。

    • ターミナルを使っている場合は、export コマンドを使います。

      Shell
      export GH_PAT="TOKEN"
      export GH_SOURCE_PAT="TOKEN"
      
    • PowerShell を使っている場合は、$env コマンドを使います。

      Shell
      $env:GH_PAT="TOKEN"
      $env:GH_SOURCE_PAT="TOKEN"
      
  4. データ所在地付き GitHub Enterprise Cloud に移行する場合は、便宜上、エンタープライズのベース API URL の環境変数を設定します。 次に例を示します。

    Shell
    export TARGET_API_URL="https://api.octocorp.ghe.com"
    

    この変数は、GitHub CLI で実行するコマンドの --target-api-url オプションと共に使用します。

手順 4: Organization を移行する

Organization を移行するには、gh gei migrate-org コマンドを使用します。

Shell
gh gei migrate-org --github-source-org SOURCE --github-target-org DESTINATION --github-target-enterprise ENTERPRISE

Note

GHE.com に移行する場合は、--target-api-url TARGET-API-URL を追加します。TARGET-API-URL は Enterprise のサブドメインのベース API URL です。 (例: https://api.octocorp.ghe.com)。

上のコマンドのプレースホルダーを次の値に置き換えます。

プレースホルダー
SOURCE移行元の Organization の名前
DESTINATION新しい Organization に付ける名前。 移行先プラットフォーム上の別の organization で共有することはできません。
エンタープライズ移行先エンタープライズのスラッグ。Enterprise アカウントの URL (https://github.com/enterprises/SLUG または https://SLUG.ghe.com) を調べることで識別できます。

手順 5: 移行を検証し、エラー ログを確認する

移行が完了したら、移行ログ リポジトリを確認することをお勧めします。 詳しくは、「GitHub Enterprise Importer の移行ログへのアクセス」を参照してください。

最後に、Organization と移行されたリポジトリの健全性チェックを実行することをお勧めします。