概览
使用 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 迁移的访问权限。
- 确认迁移者拥有管理员或超级管理员权限，并且能通过 SFTP 访问您的 Bitbucket Server 实例。
我们希望在 GitHub 中采用何种组织结构？
接下来，规划您将在 GitHub 中创建的组织结构。
在 Bitbucket Server 中，仓库被归入项目。GitHub 中，仓库归属于组织。然而，您不应默认每个 Bitbucket Server 项目对应在 GitHub 创建一个组织是最佳做法。
迁移到 GitHub 后，您应仅有一个企业账户以及少数由该企业拥有的组织。
每个迁移后的仓库将归属于其中一个组织，这可能导致每个组织内部出现大量未分组的仓库。不过，您可以通过在 GitHub 上创建团队来管理一组仓库的访问权限。更多信息，请参阅 关于组织团队。
如果您想将迁移工作分批进行，请考虑按组织进行分批。
- 决定新组织结构的形式。
- 决定是否需要将迁移工作拆分为更小的批次。
- 如果是，请决定如何拆分迁移。
执行迁移
为帮助发现可能特有于您企业的问题，我们强烈建议先进行一次试运行迁移。通过试运行，您将了解
- 特定仓库的迁移是否能够成功完成。
- 是否能够使迁移后的仓库恢复到可使用的状态。
- 迁移需要多长时间。
试运行可以随时进行，迁移期间无需暂停工作。为缩短完成试运行的时间，您可以将批次安排为连续执行。相应仓库的用户可以在自己的时间验证结果。
我们建议创建一个测试组织，作为试运行迁移的目标。您可以为所有试运行使用同一个组织，或为每个预期的目标组织创建一个测试组织。考虑在组织名称末尾添加 -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 迁移的访问权限。