阶段 6. 后续任务

检查迁移状态

首先，检查迁移是成功还是失败。

检查迁移状态的方式取决于你运行迁移的方式。

如果迁移是使用 GitHub CLI 运行的，则默认情况下，该进程将会显示迁移在迁移完成后是成功还是失败。如果迁移失败，你将看到导致失败的原因。
```
Migration completed (ID: RM_123)! State: SUCCEEDED
```
如果迁移是使用 GitHub CLI 以及可选的 --queue-only 参数运行的，则该进程会在将该迁移加入队列后立即退出，并且不会告诉你迁移是成功还是失败。可以使用 wait-for-migration 命令或通过查看迁移日志来检查迁移状态。

应查看每个已迁移存储库的迁移日志。对存储库具有读取访问权限的人员可以访问 GitHub 上的存储库的迁移日志。

默认情况下，所有存储库都作为专用存储库迁移，只有运行迁移的用户和组织所有者才有权访问存储库。如果不希望存储库是私有的，请更改可见性。

或者，可以使用 GitHub CLI 命令行更改存储库可见性。有关详细信息，请参阅gh repo editGitHub CLI文档中的信息。

例如，将YOUR_ORG替换为组织名称，以下命令会将组织的所有存储库设置为内部可见性。

Bash

export ORG=YOUR_ORG
gh repo list "$ORG" --limit 100000 --json name -q '.[].name' | xargs -I{} gh repo edit "$ORG/{}" --visibility internal

export 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 的模型”。
如果任何成员尚未通过团队成员身份具有存储库的适当访问权限，请授予该成员对存储库的访问权限。有关详细信息，请参阅“管理个人对组织仓库的访问”。

如果将 GitHub Enterprise Importer 的 IP 范围添加到了目标组织的 IP 允许列表，则可以删除这些项。如果为目标企业禁用了标识提供者的 IP 允许列表限制，现在可以重新启用它们。

如果以前使用过 Azure Pipelines 或 Azure Boards，并且想要在它们现在托管在 GitHub上时继续使用您当前的存储库，那么可以按照在 Microsoft Learn 上的以下指南来配置相应扩展。

        [将 Azure Pipelines 连接到 GitHub](https://learn.microsoft.com/en-us/azure/devops/pipelines/repos/github)

        [为 GitHub 配置 Azure Boards 应用](https://learn.microsoft.com/en-us/azure/devops/boards/github/install-github-app)

Azure DevOps 和 GitHub 之间存在一些差异，了解这些差异对你和你的开发人员会很有帮助。与他们共享 Azure DevOps 和 GitHub 之间的主要差异。