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 データは、移行元と、リポジトリまたは組織のどちらを移行するかによって異なります。

移行先の組織または企業でルールセットが有効になっている場合、移行されたリポジトリの履歴がそれらのルールに違反する可能性があります。ルールセットを無効にせずに移行を許可するには、該当する各ルールセットのバイパスリストに "Repository migrations" を追加します。このバイパスは、移行中にのみ適用されます。完了すると、すべての新しいコントリビューションにルールセットが適用されます。

バイパスを構成するには:

各エンタープライズまたは組織のルールセットに移動します。
[バイパスリスト] セクションで、[バイパスの追加] をクリックします。

       **[リポジトリの移行] を選択します**。

詳細については、「組織内のリポジトリのルールセットを作成する」および「リポジトリ移行のルールセットのバイパス設定」を参照してください。

移行元からのデータ GitHub Enterprise Server

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

Item	GHES 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>  |

          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.0	GHES 3.8.x-3.11.x	GHES 3.12.x	GHES 3.13.0 以降
Git ソース	2 GiB	10GiB	20GiB	40 GiB (パブリックプレビュー)
Metadata	2 GiB	10GiB	20GiB	40 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 で問題が発生する可能性があります。 これらの問題を回避して解決する方法の詳細については、 [AUTOTITLE](/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/troubleshooting-your-migration-with-github-enterprise-importer#team-references-are-broken-after-an-organization-migration) を参照してください。

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

リポジトリを直接、または 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 製品間の移行に関する概要」を参照してください。

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

この記事で