GitHub 製品間の移行について

GitHub Enterprise Importer が GitHub製品間でどのデータを移行できるかを確認します。

この記事の内容

GitHub 製品間の移行について

GitHub Enterprise Importer を使うと、GitHub Enterprise Server から GitHub Enterprise Cloud にデータを移行することも、GitHub.com から GitHub Enterprise Cloud 上の別のアカウントにデータを移行することもできます。

たとえば、GitHub Enterprise Importer は、お客様の会社で次を行うのに役立ちます。

  • エンタープライズを GHE.com に移行することで、データ所在地付き GitHub Enterprise Cloud を採用する
  • GitHub.com のエンタープライズ間で移行することにより、Enterprise Managed Users や新しい課金モデルなど、GitHub.com の特定の機能を導入する
  • GitHub Enterprise Server から GitHub Enterprise Cloud に移行することで、簡素化された管理と新機能の恩恵を受ける

移行元が GitHub.com のアカウントである場合は、組織間で個々のリポジトリを移行したり、エンタープライズ間で組織全体を移行したりできます。 移行元が GitHub Enterprise Server の場合は、個々のリポジトリを移行できます。

GitHub Enterprise Importer が移行するデータは、移行元と、リポジトリまたは組織のどちらを移行しているかによって異なります。

Note

移行しているリポジトリに、受信リポジトリが一致しないルールセットがある場合、この移行はブロックされます。 これらのルールセットをバイパスして移行を許可するには、ターゲット組織のすべてのデプロイ キーにルールセット バイパスを適用します。

リポジトリのルールセットは、組織レベルで設定できます。 受信リポジトリがこれらのルールセットのいずれにも一致しない場合は、それぞれにデプロイ キーバイパスを使用する必要があります。 「組織内のリポジトリのルールセットを作成する」をご覧ください。

GitHub Enterprise Cloud

への移行に関する考慮事項

GitHub Enterprise Importer を使う前に、以下の考慮事項を確認しておいてください。

  • GitHub Enterprise Cloud を既に使用している場合: GitHub Enterprise プランでは、GitHub Enterprise Cloud のデプロイを 1 つ利用できます。

    たとえば、既に GitHub.com を使用していて、GitHub Enterprise Server から GHE.com への移行も行いたい場合は、1 つのプランで両方の使用に対応することはできません。

  • Enterprise Managed Users に移行する場合: ID プロバイダーと統合してユーザー アカウントを管理する必要があります。 開始する前に、ID プロバイダーのサポート レベルを確認してください。 「Enterprise Managed Users について」を参照してください。

  • GitHub Enterprise Server から移行する場合: GitHub では特定のアクションにレート制限が適用されることに注意してください。これは、GitHub Enterprise Server では既定で無効になっています。 「REST API のレート制限」を参照してください。

  • データ所在地付き GitHub Enterprise Cloud に移行する場合: 特定の機能は使用できず、一部の機能には異なる構成または追加の構成が必要になることに注意してください。 「データ所在地付き GitHub Enterprise Cloud の機能の概要」を参照してください。

GitHub Enterprise Server から移行されるデータ

Warning

Wiki の移行は現在使用できません。 回避策として、手動で移行できます:

Shell
git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror

GitHub Enterprise Server (GHES) から移行するには、GHES バージョン 3.4.1 以降が必要です。 移行されるデータは、使用しているバージョンによって異なります。

ItemGHES 3.4.1 以降GHES 3.5.0 以降
Git ソース (コミット履歴を含む)
Pull Request
問題
マイルストーン
Wiki
GitHub Actionsのワークフロー
コミットのコメント
Webhook (移行後に再度有効にする必要があります。「Webhook の有効化」を参照してください)
ブランチ保護
GitHub Pages の設定
上記のデータのユーザー履歴
添付ファイル (「ファイルのアタッチ」参照)
リリース

GHES のバージョンに応じて、リポジトリあたりの異なるサイズ制限が適用されます。

制限GHES <3.8.0GHES 3.8.0 以降
Git ソース2GB10 GB
メタデータ2GB10 GB

移行されないデータ

現時点では、次のデータは移行されません。

  • 監査ログ
  • Code scanning の結果
  • コミット状態チェック
  • Dependabot のアラート
  • Dependabot のシークレット
  • リポジトリ レベルでのディスカッション
  • issue のコメントと pull request のコメントの履歴を編集する
  • リポジトリ間のフォーク関係 (「フォークについて」を参照)
  • GitHub Actions シークレット、変数、環境、セルフホステッド ランナー、より大きなランナー、またはワークフロー実行履歴
  • GitHub Apps と GitHub App のインストール
  • Git LFS オブジェクトと大きなバイナリ (Git LFS を使うリポジトリは引き続きサポートされます。「GitHub Enterprise Importerの制限事項」をご覧ください)
  • GitHub Packages 内のパッケージ
  • Organization レベルのプロジェクト (クラシック)
  • Projects (新しいプロジェクト エクスペリエンス)
  • 異なるリポジトリ内の pull request と issue 間の参照 (「自動リンクされた参照と URL」を参照)
  • secret scanning の結果の修復状態
  • ユーザー アカウントが所有するリポジトリ
  • リポジトリの星
  • リポジトリ ウォッチャー
  • ルールセット
  • タグ保護ルール
  • ユーザーのプロファイル、SSH キー、署名キー、または personal access tokens
  • Webhook のシークレット
  • Teams
  • リポジトリへのユーザーまたはチームのアクセス
  • pull request のリポジトリ設定

ブランチ保護

ブランチ保護により、特定のブランチ名またはブランチ名パターンに、指定した一連の規則が適用されます。 詳しくは、「保護されたブランチについて」を参照してください。

ブランチ保護は常に移行されますが、特定の規則は移行されません。 次のブランチ保護規則は移行されません。

  • 特定のアクターが必須の pull request をバイパスできるようにする
  • 最新のプッシュの承認を要求する
  • Require deployments to succeed before merging
  • ブランチをロックする
  • 一致するブランチを作成するプッシュを制限する
  • フォースプッシュを許可

また、次の制限事項が適用されます。

  • ブランチ保護規則で、規則の適用対象外とするユーザー、チーム、またはアプリを必要に応じて指定できる場合 ("pull request レビューを無視できるユーザーを制限する" など)、例外は移行されません。
  • "強制プッシュを許可する" 規則が "強制プッシュできるユーザーを指定する" モードで有効になっている場合、規則は移行されません。

GitHub.com から移行されるデータ

移行元が GitHub.com のアカウントである場合は、組織間で個々のリポジトリを移行したり、エンタープライズ間で組織全体を移行したりできます。

組織の移行されたデータ

Organization を移行すると、移行先の Enterprise アカウント内に新しい Organization が作成されます。 その後、次のデータが新しい Organization に移行されます。

  • Teams
  • リポジトリ
  • リポジトリへのチーム アクセス
  • メンバー特権
  • 組織レベルの Webhook (移行後に再度有効にする必要があります。「Webhook の有効化」を参照してください)
  • Organization 内に作成された新しいリポジトリの既定のブランチ名

すべてのリポジトリは、可視性を非公開として移行されます。 リポジトリの可視性を公開または内部に設定する場合は、移行後に UI または API を使用して行うことができます。

チーム メンバーシップは移行されません。 移行後、移行されたチームにメンバーを追加する必要があります。 詳しくは、「GitHub 製品間の移行に関する概要」を参照してください。

注: チームへの参照 (@octo-org/octo-team など) は、Organization の移行の一部として更新されません。 これにより、CODEOWNERS ファイルが期待どおりに動作しないなど、移行先の Organization で問題が発生する可能性があります。 これらの問題を回避および解決する方法について詳しくは、「GitHub Enterprise Importer を使用した移行のトラブルシューティング」を参照してください。

リポジトリの移行されたデータ

リポジトリを直接、または Organization 移行の一部として移行すると、次のデータのみが移行されます。

  • Git ソース (コミット履歴を含む)
  • Pull Request
  • issue
  • マイルストーン
  • Wiki (添付ファイルを除く)
  • GitHub Actionsのワークフロー
  • コミットのコメント
  • アクティブな Webhook (移行後に再度有効にする必要があります。「Webhook の有効化」を参照してください)
  • リポジトリトピック
  • リポジトリ設定
    • ブランチ保護 (詳しくは「ブランチ保護」を参照してください)
    • GitHub Pages の設定
    • 自動リンク参照
    • GitHub Advanced Security の設定
    • pull request の設定
      • head ブランチを自動的に削除する
      • 自動マージを許可する
      • マージ コミットを許可する (コミット メッセージの設定が既定のメッセージにリセットされる)
      • スカッシュ マージを許可する (コミット メッセージの設定が既定のメッセージにリセットされる)
      • リベース マージを許可する
  • リリース (リポジトリあたり最大 10 GB)
  • 上記のデータのユーザー履歴
  • 添付ファイル (「ファイルのアタッチ」参照)

移行されないデータ

現時点では、次のデータは移行されません。

  • Codespaces のシークレットの * 監査ログ
  • Code scanning の結果
  • コミット状態チェック
  • Dependabot のアラート
  • Dependabot のシークレット
  • リポジトリ レベルでのディスカッション
  • issue のコメントと pull request のコメントの履歴を編集する
  • リポジトリ間のフォーク関係 (「フォークについて」を参照)
  • GitHub Actions シークレット、変数、環境、セルフホステッド ランナー、より大きなランナー、またはワークフロー実行履歴
  • GitHub Apps と GitHub App のインストール
  • Git LFS オブジェクトと大きなバイナリ (Git LFS を使うリポジトリは引き続きサポートされます。「GitHub Enterprise Importerの制限事項」をご覧ください)
  • GitHub Packages 内のパッケージ
  • Organization レベルのプロジェクト (クラシック)
  • Projects (新しいプロジェクト エクスペリエンス)
  • 異なるリポジトリ内の pull request と issue 間の参照 (「自動リンクされた参照と URL」を参照)
  • secret scanning の結果の修復状態
  • ユーザー アカウントが所有するリポジトリ
  • リポジトリの星
  • リポジトリ ウォッチャー
  • ルールセット
  • タグ保護ルール
  • ユーザーのプロファイル、SSH キー、署名キー、または personal access tokens
  • Webhook のシークレット
  • リポジトリへのユーザー アクセス

リポジトリを直接移行する場合、チームと、リポジトリへのチーム アクセスは移行されません。

ブランチ保護

ブランチ保護により、特定のブランチ名またはブランチ名パターンに、指定した一連の規則が適用されます。 詳しくは、「保護されたブランチについて」を参照してください。

ブランチ保護は常に移行されますが、特定の規則は移行されません。 次のブランチ保護規則は移行されません。

  • 特定のアクターが必須の pull request をバイパスできるようにする
  • 最新のプッシュの承認を要求する
  • Require deployments to succeed before merging
  • ブランチをロックする
  • 一致するブランチを作成するプッシュを制限する
  • フォースプッシュを許可

また、次の制限事項が適用されます。

  • ブランチ保護規則で、規則の適用対象外とするユーザー、チーム、またはアプリを必要に応じて指定できる場合 ("pull request レビューを無視できるユーザーを制限する" など)、例外は移行されません。
  • "強制プッシュを許可する" 規則が "強制プッシュできるユーザーを指定する" モードで有効になっている場合、規則は移行されません。

移行されたデータに関する制限

GitHub Enterprise Importer で何を移行できるかについては、制限があります。 GitHub の制限に起因するものもあれば、GitHub Enterprise Importer 自体の制限事項であるものもあります。

GitHub の制限事項

  • 1 つの Git コミットに対する 2 GB のサイズ制限: Git リポジトリ内の 1 つのコミットが 2 GB を超えることはできません。 いずれかのコミットが 2 GB を超える場合は、そのコミットを、それぞれが 2 GB 以下の小さなコミットに分割する必要があります。
  • Git 参照の 255 バイトの制限: "ref" と呼ばれる 1 つの Git 参照には、255 バイトを超える名前を付けることはできません。 通常、これは、参照の長さは 255 文字を超えることはできませんが、絵文字などの ASCII 以外の文字は複数バイトを消費する可能性があることを意味します。 いずれかの Git 参照が大きすぎる場合は、明確なエラー メッセージが返されます。
  • 100 MB のファイル サイズ制限: Git リポジトリ内の 1 つのファイルが 100 MB を超えることはできません。 大きなファイルを格納するためには、Git LFS を使用することを検討してください。 詳しくは、「大きなファイルを管理する」を参照してください。

GitHub Enterprise Importer の制限事項

  • Git リポジトリの 10 GB のサイズ制限: この制限はソース コードにのみ適用されます。 リポジトリ アーカイブが制限を超えているかどうかをチェックするには、git-sizer ツールを使用して出力の合計 BLOB サイズを確認します。 git-sizer ツールは、大きなファイル、BLOB サイズ、コミット サイズ、移行に影響する恐れがあるツリー数に関連する潜在的な問題を特定することにも役立ちます。
  • メタデータの 10 GB の制限: 10 GB を超えるメタデータを持つリポジトリは、Importer で移行できません。 メタデータには、issue、pull request、リリース、添付ファイルが含まれます。 ほとんどの場合、大きなメタデータの原因は、リリースにアタッチされたバイナリ資産です。 migrate-repo コマンドの --skip-releases フラグを使用して移行からリリースを除外し、移行後にリリースを手動で移動できます。
  • Git LFS オブジェクトは移行されない: Importer で、Git LFS を使用するリポジトリを移行できますが、LFS オブジェクト自体は移行されません。 これらは、移行完了後にフォローアップ タスクとして移行先にプッシュできます。 詳しくは、「リポジトリを複製する」を参照してください。
  • 必要なフォローアップ タスク: GitHub 製品間で移行する場合、特定の設定は移行されず、新しいリポジトリで再構成する必要があります。 それぞれの移行後に完了する必要があるフォローアップ タスクの一覧については、「GitHub 製品間の移行に関する概要」を参照してください。
  • 遅延コード検索機能: リポジトリ移行後の検索インデックスの再作成には数時間かかることがあります。また、インデックスの再作成が完了するまで、コード検索で予期しない結果が返される可能性があります。
  • Organization 用に構成されたルールセットによって移行が失敗する可能性がある: たとえば、コミット作成者のメール アドレスが @monalisa.cat で終わるように要求するルールを構成し、移行するリポジトリにこのルールに準拠していないコミットが含まれている場合、移行は失敗します。 ルールセットについて詳しくは、「ルールセットについて」をご覧ください。
  • マネキンの内容が検索できない場合あり: マネキンは、インポートされた内容 (問題、pull request、コメントなど) が関連付けられているプレースホルダー ユーザーです。 割り当てられた問題など、マネキンに関連付けられている内容を検索しても、問題が見つからない可能性があります。 マネキンが回収されると、新しい所有者を介してコンテンツが見つかります。 詳しくは、「GitHub Enterprise Importer のマネキンの回収」を参照してください。

作業の開始

GitHub 製品間で移行する前に、移行の実行方法を計画する必要があります。 データを移行する前に、移行を実行する名前未登録ユーザーを選択する必要があります。　 移行元と移行先の両方に必要なアクセス権をそのユーザーに付与する必要があります。　 また、最初に試用版の移行を実行することをお勧めします。

最初から最後までの移行プロセスの概要については、「GitHub 製品間の移行に関する概要」を参照してください。