このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-09-25. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください。

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

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

この記事の内容

Azure DevOps からの移行について

GitHub Enterprise Importer を使用して、 Azure DevOps からリポジトリを GitHub Enterprise Cloud に移行できます。

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 リポジトリ内の 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 のマネキンの回収」を参照してください。

作業の開始

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

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