GitHub Enterprise Importer を使用したGitHub製品間の移行について

          GitHub Enterprise Importer製品間で移行できるデータ GitHubについて説明します。

この記事で

GitHub製品間の移行について

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

移行ソースが 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 ソース (コミット履歴を含む)
Pull Request
問題
マイルストーン
Wiki
          GitHub Actions ワークフロー | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  |

コミットのコメント | | | Webhook (移行後に再度有効にする必要があります。「Webhook の有効化」を参照してください) | | | ブランチ保護 | | |

          GitHub Pages 設定 | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  |

上記のデータのユーザー履歴 | | | 添付ファイル (「ファイルを添付」を参照してください) | | | リリース | | |

圧縮アーカイブには、GHES のバージョンに応じて、リポジトリごとに異なるサイズ制限が適用されます。

制限GHES <3.8.0GHES 3.8.x-3.11.xGHES 3.12.xGHES 3.13.0 以降
Git ソース2 GiB10GiB20GiB40 GiB (パブリック プレビュー)
Metadata2 GiB10GiB20GiB40 GiB (パブリック プレビュー)

移行されないデータ

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

  • 監査ログ
  • Code scanning 結果
  • Codespaces 秘匿情報
  • コミット状態チェック
  • Dependabot アラート
  • Dependabot 秘匿情報
  • リポジトリ レベルでのディスカッション
  • issue のコメントとプル リクエストのコメントの履歴を編集する
  • リポジトリ間のフォーク関係 (「フォークについて」を参照)
  • GitHub Actions シークレット、変数、環境、セルフホステッドランナー、より大きなランナー、ワークフローアーティファクト、またはワークフロー実行履歴
  • GitHub アプリとGitHub アプリのインストール
  • Git LFSオブジェクトと大きなバイナリ (Git LFS を使用するリポジトリは引き続きサポートされています。GitHub Enterprise Importerの制限事項を参照)
  • リベース マージされたプル リクエストへのコミットからのリンク
  • pull request、issue、release、および comment の本文におけるユーザー、チーム、組織の言及（元のユーザー名は残ります）
  • パッケージ GitHub Packages
  • Projects (新しいプロジェクト エクスペリエンス)
  • 異なるリポジトリ間におけるプル リクエストと 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
  • 問題
  • マイルストーン
  • Wiki (添付ファイルを除く)
  • GitHub Actions ワークフロー
  • コミットのコメント
  • アクティブな Webhook (移行後に再度有効にする必要があります。「Webhook の有効化」を参照してください)
  • リポジトリトピック
  • リポジトリ設定
    • ブランチ保護 (詳しくは「ブランチ保護」を参照してください)
    • GitHub Pages 設定
    • 自動リンク参照
    • pull request の設定
      • head ブランチを自動的に削除する
      • 自動マージを許可する
      • マージ コミットを許可する (コミット メッセージの設定が既定のメッセージにリセットされる)
      • スカッシュ マージを許可する (コミット メッセージの設定が既定のメッセージにリセットされる)
      • リベース マージを許可する
  • リリース (リポジトリあたり最大 10 GiB)
  • 上記のデータのユーザー履歴
  • 添付ファイル (「ファイルを添付」を参照してください)

移行されないデータ

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

  • 監査ログ
  • Code scanning 結果
  • Codespaces 秘匿情報
  • コミット状態チェック
  • Dependabot アラート
  • Dependabot 秘匿情報
  • リポジトリ レベルでのディスカッション
  • issue のコメントとプル リクエストのコメントの履歴を編集する
  • リポジトリ間のフォーク関係 (「フォークについて」を参照)
  • GitHub Actions シークレット、変数、環境、セルフホステッドランナー、より大きなランナー、ワークフローアーティファクト、またはワークフロー実行履歴
  • GitHub アプリとGitHub アプリのインストール
  • Git LFSオブジェクトと大きなバイナリ (Git LFS を使用するリポジトリは引き続きサポートされています。GitHub Enterprise Importerの制限事項を参照)
  • リベース マージされたプル リクエストへのコミットからのリンク
  • pull request、issue、release、および comment の本文におけるユーザー、チーム、組織の言及（元のユーザー名は残ります）
  • パッケージ GitHub Packages
  • Projects (新しいプロジェクト エクスペリエンス)
  • 異なるリポジトリ間におけるプル リクエストと 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 GiB サイズの制限: Git リポジトリ内の 1 つのコミットは、2 GiB を超える可能性はありません。 いずれかのコミットが 2 GiB を超える場合は、コミットを 2 GiB 以下の小さなコミットに分割する必要があります。
  • Git 参照の 255 バイトの制限: "ref" と呼ばれる 1 つの Git 参照には、255 バイトを超える名前を付けることはできません。 通常、これは、参照の長さは 255 文字を超えることはできませんが、絵文字などの ASCII 以外の文字は複数バイトを消費する可能性があることを意味します。 いずれかの Git 参照が大きすぎる場合は、明確なエラー メッセージが返されます。
  • 100 MiB ファイル サイズの制限: 移行が完了すると、Git リポジトリ内の 1 つのファイルは 100 MiB を超えなくなります。 リポジトリの移行中に、この制限は 400 MiB に引き上げられます。 大きなファイルを格納するためには、Git LFS を使用することを検討してください。 詳しくは、「大きなファイルを管理する」をご覧ください。

GitHub Enterprise Importer の制限事項

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

概要

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

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