GitHub 製品間の移行について

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

この記事の内容

GitHub 製品間の移行について

GitHub Enterprise Importer を使用すると、GitHub Enterprise Server から GitHub Enterprise Cloud にデータを移行することも、GitHub Enterprise Cloud 上のアカウント間でデータを移行することもできます。 詳しくは、「GitHub Enterprise Importer について」を参照してください。

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

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

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

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

ItemGHES 3.4.1 以降GHES 3.5.0 以降
Git ソース (コミット履歴を含む)
プルリクエスト
問題
マイルストーン
Wikis
リポジトリ レベルのプロジェクト (クラシック)
GitHub Actionsのワークフロー
コミットのコメント
アクティブな Webhook
ブランチ保護
GitHub Pages の設定
上記のデータのユーザー履歴
添付ファイル (「ファイルのアタッチ」参照)
リリース

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

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

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

  • すべての Projects (新しいプロジェクト エクスペリエンス)
  • Code scanning の結果
  • コミット状態チェック
  • Dependabot のアラート
  • Dependabot のシークレット
  • リポジトリ レベルでのディスカッション
  • issue のコメントと pull request のコメントの履歴を編集する
  • リポジトリ間のフォーク関係 (「フォークについて」を参照)
  • GitHub Actions シークレット、変数、環境、セルフホステッド ランナー、より大きなランナー、またはワークフロー実行履歴
  • GitHub Codespaces のシークレット
  • GitHub Apps と GitHub App のインストール
  • Git LFS オブジェクトと大きなバイナリ (Git LFS を使うリポジトリは引き続きサポートされます。「GitHub Enterprise Importerの制限事項」をご覧ください)
  • GitHub Packages 内のパッケージ
  • Organization レベルのプロジェクト (クラシック)
  • 異なるリポジトリ内の 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)
  • 上記のデータのユーザー履歴
  • 添付ファイル (「ファイルのアタッチ」参照)

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

  • すべての Projects (新しいプロジェクト エクスペリエンス)
  • Code scanning の結果
  • コミット状態チェック
  • Dependabot のアラート
  • Dependabot のシークレット
  • リポジトリ レベルでのディスカッション
  • issue のコメントと pull request のコメントの履歴を編集する
  • リポジトリ間のフォーク関係 (「フォークについて」を参照)
  • GitHub Actions シークレット、変数、環境、セルフホステッド ランナー、より大きなランナー、またはワークフロー実行履歴
  • GitHub Codespaces のシークレット
  • GitHub Apps と GitHub App のインストール
  • Git LFS オブジェクトと大きなバイナリ (Git LFS を使うリポジトリは引き続きサポートされます。「GitHub Enterprise Importerの制限事項」をご覧ください)
  • GitHub Packages 内のパッケージ
  • Organization レベルのプロジェクト (クラシック)
  • 異なるリポジトリ内の 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.com の制限に起因するものもあれば、GitHub Enterprise Importer 自体の制限事項であるものもあります。

GitHub.com

の制限事項

  • 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 製品間の移行に関する概要」を参照してください。