概述
使用 GitHub Enterprise Importer，您可以按仓库逐个迁移到 GitHub Enterprise Cloud。有关更多信息，请参阅“关于 GitHub Enterprise Importer”。
如果您要从 Bitbucket Server 迁移，可以使用本指南来规划和实施迁移并完成后续任务。
规划迁移
要规划迁移，请自问以下问题。
我们多久需要完成迁移？
确定您的时间线，这将在很大程度上决定您的方法。确定时间线的首要步骤是盘点您需要迁移的内容。
- 存储库数量
- 拉取请求数量
迁移时间主要取决于存储库中拉取请求的数量。如果您想迁移 1,000 个存储库，每个存储库平均有 100 个拉取请求，只有 50 个用户贡献了这些存储库，您的迁移可能会非常快。如果您只想迁移 100 个存储库，但每个存储库平均有 75,000 个拉取请求，并且有 5,000 个用户，迁移将花费更长时间，并且需要更多规划和测试。
盘点完您需要迁移的存储库后，您可以将您的盘点数据与您期望的时间线进行比较。如果您的组织能够承受更高程度的变更，那么您可能能够一次性迁移所有存储库，并在几天内完成迁移工作。但是，您可能会有多个无法同时迁移的团队。在这种情况下，您可能希望将迁移分批进行，并错开时间以适应团队的时间线，从而延长您的迁移工作。
- 确定您需要迁移多少个存储库和拉取请求。
- 要了解团队何时可以准备好迁移，请采访利益相关者。
- 完整查看本指南的其余部分，然后决定迁移时间线。
我们是否了解将要迁移的内容？
确保您和您的利益相关者了解 GitHub Enterprise Importer 可以迁移哪些数据。
对于从 Bitbucket Server 迁移，GitHub Enterprise Importer 仅迁移 Git 存储库和拉取请求。任何其他资产，例如 CI 管道，将保留在 Bitbucket Server 中。
由于 GitHub 中的权限与 Bitbucket Server 中的权限不同，因此 GitHub Enterprise Importer 不会尝试从 Bitbucket Server 迁移存储库权限。有关更多信息，请参阅“配置权限”。
- 查看从 Bitbucket Server 迁移的数据。有关更多信息，请参阅“关于从 Bitbucket Server 迁移到 GitHub Enterprise Cloud”。
- 列出您需要手动迁移或重新创建的任何数据。
谁将运行迁移？
要迁移存储库，您必须是 GitHub 目标组织的组织所有者，或者组织所有者必须授予您迁移者角色。
您还必须拥有 Bitbucket Server 实例所需的权限和访问权限。
- 管理员或超级管理员权限
- 如果您的 Bitbucket Server 实例运行 Linux，则使用受支持的 SSH 私钥访问实例的 SFTP 访问权限（请参阅“管理来自 Bitbucket Server 的迁移的访问权限”）。
- 如果您的 Bitbucket Server 实例运行 Windows，则访问实例的文件共享 (SMB) 权限。
- 决定您是否希望目标组织的组织所有者执行您的迁移，或者您是否需要将迁移者角色授予其他人。
- 如果您选择授予迁移者角色，请决定您将授予该角色的个人或团队。
- 将迁移者角色授予该个人或团队。有关更多信息，请参阅“管理来自 Bitbucket Server 的迁移的访问权限”。
- 确认该人员已正确配置个人访问令牌以满足所有访问要求。有关更多信息，请参阅“管理来自 Bitbucket Server 的迁移的访问权限”。
- 确认迁移者拥有 Bitbucket Server 实例的管理员或超级管理员权限和 SFTP 访问权限。
我们希望在 GitHub 中使用什么组织结构？
接下来，规划您将在 GitHub 中创建的组织结构。
在 Bitbucket Server 中，存储库被分组到项目中。在 GitHub 中，存储库由组织拥有。但是，您不应该假设最佳方法是在 GitHub 中为 Bitbucket Server 中的每个项目创建一个组织。
迁移到 GitHub 后，您应该只有一个企业帐户和少量由该企业拥有的组织。
每个迁移的存储库将由这些组织之一拥有，这可能会导致每个组织中出现大量未分组的存储库列表。但是，您可以通过在 GitHub 上创建团队来管理对存储库组的访问权限。有关更多信息，请参阅“关于团队”。
如果您想将迁移工作分成批次，请考虑按组织进行批次处理。
- 确定新的组织结构。
- 确定是否需要将迁移工作分成更小的批次。
- 如果是，请确定如何划分迁移。
运行迁移
完成计划后，您可以开始实际迁移。为了帮助发现迁移期间和迁移后可能特定于您企业的潜在问题，我们强烈建议对所有迁移进行试运行。在解决试运行中发现的任何问题后，您可以运行生产迁移。
试运行有助于您确定几个关键信息。
- 给定存储库的迁移是否可以成功完成
- 您是否可以将存储库恢复到用户可以成功开始工作的状态
- 迁移运行需要多长时间，这对于规划迁移时间表和设定利益相关者的期望很有用
试运行不需要太多时间协调。GitHub Enterprise Importer 永远不会要求对正在迁移的存储库的用户进行停机。但是，我们建议在生产迁移期间停止工作，以确保在迁移期间不会创建新数据，否则这些数据将从迁移后的存储库中丢失。这对于试运行来说不是问题，因此试运行可以在任何时候进行。为了缩短完成试运行所需的时间，您可以将试运行的批次安排在一起。然后，这些存储库的用户可以在自己的时间内验证结果。
我们建议创建一个测试组织，用作试运行的目的地。您可以对所有试运行使用单个组织，也可以为每个目标组织创建一个测试组织。考虑在组织名称末尾包含 -sandbox，以明确说明这些组织仅用于迁移验证，而不是用于生产。完成试运行后，您可以删除测试组织。
- 为试运行创建一个测试组织。
- 运行试运行。
- 完成以下描述的试运行迁移的后续任务。
- 请用户验证迁移结果。
- 解决试运行迁移中发现的任何问题。
- 如果您的目标使用 IP 允许列表，请配置该列表以允许 GitHub Enterprise Importer 访问。有关更多信息，请参阅“管理从 Bitbucket Server 迁移的访问权限”。
- 运行生产迁移。有关更多信息，请参阅“将存储库从 Bitbucket Server 迁移到 GitHub Enterprise Cloud”。
- 可选：删除测试组织。
完成后续任务
每次迁移完成后，您都需要完成一些额外的任务，才能使存储库准备好工作。
检查迁移状态
首先，检查您的迁移是成功还是失败。
检查迁移状态的方式取决于您运行迁移的方式。
-
如果您使用 GitHub CLI 运行迁移，默认情况下，该过程将在迁移完成后显示迁移是成功还是失败。如果迁移失败，您将看到失败的原因。
Migration completed (ID: RM_123)! State: SUCCEEDED -
如果您使用 GitHub CLI 运行迁移，并使用可选的
--queue-only参数，该过程将在排队迁移后立即退出，并且不会告诉您迁移是成功还是失败。您可以使用wait-for-migration命令或查看迁移日志来检查迁移的状态。 -
如果您使用 GraphQL API 运行迁移，您可以查询
RepositoryMigration对象上的state和failureReason字段。
如果迁移失败，迁移日志可能包含有关失败原因的更多信息。有关更多信息，请参阅“查看迁移日志”。
查看迁移日志
查看每个迁移存储库的迁移日志。有关更多信息，请参阅“访问 GitHub Enterprise Importer 的迁移日志”。
如果迁移失败，日志中可能包含有关失败原因的更多信息。
如果迁移成功，迁移日志中可能包含警告，表示某些特定数据（例如拉取请求、问题或评论）未迁移或迁移时存在注意事项。
有关了解迁移警告的更多信息，请参阅“使用 GitHub Enterprise Importer 排查迁移问题”。在查看任何迁移警告后，您需要决定是否可以接受这些警告并继续进行。
设置仓库可见性
所有仓库都以私有方式迁移，只有运行迁移的用户和组织所有者可以访问该仓库。如果您不希望仓库为私有，请更改可见性。
- 您可以在浏览器中更改仓库的可见性。有关更多信息，请参阅“设置仓库可见性”。
- 或者，您可以使用 GitHub CLI 从命令行更改仓库可见性。您甚至可以将此命令添加到用于运行迁移的脚本中。有关更多信息，请参阅 GitHub CLI 文档中的
gh repo edit。
配置权限
由于 GitHub 中的权限与 Bitbucket Server 中的权限不同，因此 GitHub Enterprise Importer 不会尝试从 Bitbucket Server 迁移仓库权限。
要授予对迁移仓库的访问权限，您可以创建团队并为每个团队授予对仓库的访问权限。
- 创建团队。有关更多信息，请参阅“创建团队”。
- 将组织成员添加到团队。有关更多信息，请参阅“将组织成员添加到团队”。
- 为每个团队授予对仓库的访问权限。有关更多信息，请参阅“管理团队对组织仓库的访问权限”。
回收人偶
使用 GitHub Enterprise Importer 运行迁移后，迁移仓库中的所有用户活动（Git 提交除外）都将归因于称为人偶的占位符身份。
您可以使用 GitHub CLI 或浏览器将每个虚拟用户的历史记录重新归属给组织成员。如果您使用 GitHub CLI，则可以批量回收虚拟用户。有关更多信息，请参阅“回收 GitHub Enterprise Importer 的虚拟用户”。
注意：只有组织所有者可以回收虚拟用户。如果您被授予迁移者角色，请联系组织所有者执行此步骤。
- 决定是否要回收虚拟用户。
- 计划何时完成回收。
- 回收虚拟用户。
- 如果任何成员尚未通过团队成员身份获得对存储库的适当访问权限，请授予成员对存储库的访问权限。有关更多信息，请参阅“管理个人对组织存储库的访问权限”。
配置 IP 允许列表
如果您将 GitHub Enterprise Importer 的 IP 范围添加到目标组织的 IP 允许列表中，则可以删除这些条目。如果您为目标企业禁用了身份提供商的 IP 允许列表限制，则现在可以重新启用它们。
有关更多信息，请参阅“管理从 Bitbucket Server 迁移的访问权限”。