Azure DevOps から GitHub Enterprise クラウドへの移行について

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

この記事の内容

Azure DevOps からの移行について

GitHub Enterprise Importer を使って、リポジトリを Azure DevOps から GitHub Enterprise Cloud (GitHub.com または GHE.com) に移行できます。

GitHub Enterprise Importer を使用して移行できるのは Azure DevOps Cloud からのみであり、Azure DevOps Server からは移行できません。 現在 Azure DevOps Server を使用していて、GitHub に移行する場合は、まず Azure DevOps Cloud に移行できます。 詳しくは、Azure サイトの「Azure DevOps への移行」を参照してください。

移行されるデータ

現在、次のリポジトリ データのみについて、Azure DevOps から GitHub Enterprise Cloud への移行がサポートされています。

  • Git ソース (コミット履歴を含む)
  • Pull Request
  • pull request のユーザー履歴
  • pull request の作業項目リンク
  • pull request の添付ファイル
  • リポジトリのブランチ ポリシー (ユーザー スコープのブランチ ポリシーとリポジトリ間ブランチ ポリシーは含まれません)

Azure Pipelines を GitHub Actions に移行する場合は、担当の GitHub アカウント マネージャーにお問い合わせください。

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

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 リポジトリ内に 100 MB を超えるファイルは存在できません。 リポジトリの移行中は、この制限が 400 MB に増やされます。 大きなファイルを格納するためには、Git LFS を使用することを検討してください。 詳しくは、「大きなファイルを管理する」をご覧ください。

GitHub Enterprise Importer の制限事項

  • Git リポジトリの 40 GB のサイズ制限 (パブリック プレビュー): この制限はソース コードにのみ適用されます。 リポジトリ アーカイブが制限を超えているかどうかをチェックするには、git-sizer ツールを使用して出力の合計 BLOB サイズを確認します。 git-sizer ツールは、大きなファイル、BLOB サイズ、コミット サイズ、移行に影響する恐れがあるツリー数に関連する潜在的な問題を特定することにも役立ちます。
  • 400 MB file size limit: When migrating a repository with GitHub Enterprise Importer, no single file in your Git repository can be larger than 400 MB. Consider using Git LFS for storing large files. For more information, see 大きなファイルを管理する.
  • Git LFS objects not migrated: The Importer can migrate repositories that use Git LFS, but the LFS objects themselves will not be migrated. They can be pushed to your migration destination as a follow-up task after the migration is complete. For more information, see リポジトリを複製する.
  • Follow-up tasks required: When migrating between GitHub products, certain settings are not migrated and must be reconfigured in the new repository. For a list of follow-up tasks you'll need to complete after each migration, see GitHub 製品間の移行に関する概要.
  • Delayed code search functionality: Re-indexing the search index can take a few hours after a repository is migrated, and code searches may return unexpected results until re-indexing is complete.
  • Rulesets configured for your organization can cause migrations to fail: For example, if you configured a rule that requires email addresses for commit authors to end with @monalisa.cat, and the repository you're migrating contains commits that don't comply with this rule, your migration will fail. For more information about rulesets, see ルールセットについて.
  • Mannequin content might not be searchable: Mannequins are placeholder users to which imported content (such as issues, pull requests, comments, etc.) is associated. When you search for content associated with a mannequin, such as assigned issues, the issues may not be found. Once a mannequin is reclaimed, the content should be found via the new owner. For more information, see GitHub Enterprise Importer のマネキンの回収.

概要

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

最初から最後までの移行プロセスの概要については、「Azure DevOps から GitHub Enterprise クラウドへの移行の概要」を参照してください。