检查迁移状态
首先，检查您的迁移是成功还是失败。
检查迁移状态的方法取决于您如何运行迁移。
-
如果您使用 GitHub CLI 运行迁移，默认情况下，迁移完成后，过程会显示迁移是成功还是失败。如果迁移失败，您将看到失败原因。
Migration completed (ID: RM_123)! State: SUCCEEDED -
如果您在使用 GitHub CLI 时加入了可选的
--queue-only参数，过程将在将迁移加入队列后立即退出，并不会告知迁移是成功还是失败。您可以使用wait-for-migration命令或审查迁移日志来检查迁移状态。
审查迁移日志
您应该审查每个已迁移仓库的迁移日志。拥有仓库读取权限的用户可以在 GitHub 上访问该仓库的迁移日志。
-
在目标组织中导航至已迁移的仓库。
-
在仓库名称下，点击 议题。
-
点击标题为 “Migration Log” 的议题。
了解更多，请参阅访问 GitHub Enterprise Importer 的迁移日志。
设置仓库可见性
默认情况下，所有仓库都会以私有方式迁移，只有执行迁移的用户和组织所有者能够访问该仓库。如果您不希望仓库保持私有，请更改可见性。
-
您可以在浏览器中更改仓库的可见性。了解更多，请参阅设置仓库可见性。
-
或者，您也可以使用 GitHub CLI 在命令行中更改仓库可见性。了解更多，请参阅 GitHub CLI 文档中的
gh repo edit。例如，将 YOUR_ORG 替换为您的组织名称，下面的命令将把该组织的所有仓库设为 internal（内部）可见性。
Bash export ORG=YOUR_ORG gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internalexport ORG=YOUR_ORG gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal
回收人偶
使用 GitHub Enterprise Importer 运行迁移后，已迁移仓库中的所有用户活动（Git 提交除外）都会归因于称为人偶的占位身份。
注意
只有组织所有者可以回收人偶。如果您被授予迁移者角色，请联系组织所有者执行此步骤。
- 决定是否要回收人偶。
- 规划何时完成回收工作。
- 回收人偶。您可以使用 GitHub CLI 或在浏览器中将每个人偶的历史重新归属给组织成员。如果使用 GitHub CLI，您可以批量回收人偶。了解更多，请参阅GitHub Enterprise Importer 的人偶回收。
- 如果其中任何成员尚未通过团队成员资格获得对仓库的适当访问权限，请为这些成员授予仓库访问权限。了解更多，请参阅管理个人对组织仓库的访问。
配置 IP 访问白名单
如果您已将 GitHub Enterprise Importer 的 IP 范围添加到目标组织的 IP 访问白名单中，您可以将这些条目移除。如果您已为目标企业禁用了身份提供商的 IP 白名单限制，现在可以重新启用它们。
配置 Azure Pipelines 和 Azure Boards
如果您之前使用过 Azure Pipelines 或 Azure Boards，并希望在仓库迁移至 GitHub 后继续使用它们，可按照 Microsoft Learn 上的指南配置相应扩展。
在新环境中支持您的开发者
Azure DevOps 与 GitHub 之间存在一些差异，了解这些差异对您和您的开发者很有帮助。请将Azure DevOps 与 GitHub 的关键差异分享给他们。