# 准备从Azure DevOps迁移到 GitHub

通过了解时间线、迁移的数据以及组织结构来规划迁移。

## 确定需要迁移的内容量

确定时间线，这将在很大程度上决定你的方法。 若要确定时间线，第一步是获取需迁移内容的清单。

* 存储库数目
* 拉取请求数

> \[!NOTE] 迁移时间主要基于存储库中的拉取请求数。 如果要迁移 1,000 个存储库，并且每个存储库平均有 100 个拉取请求，则迁移速度可能会非常快。 如果只想迁移 100 个存储库，但每个存储库平均有 75,000 个拉取请求，迁移需要更长的时间，并且需要更多的规划和测试。

我们建议在ADO2GH extension of the GitHub CLI中使用`inventory-report`命令。 此命令将连接到 Azure DevOps API，然后创建多个 CSV 文件。
`repos.csv` 包含有关存储库的信息，包括拉取请求数。

若要生成 CSV 文件，请使用以下命令，将 `YOUR_ADO_ORG` 替换为您在 Azure DevOps 上的组织。

```shell copy
gh ado2gh inventory-report --ado-org YOUR_ADO_ORG
```

获取需要迁移的存储库清单后，根据所需的时间线权衡清单数据。

* 如果组织能够承受更高程度的更改，则可以一次性迁移所有存储库，在几天内完成迁移工作。
* 如果你的团队无法同时迁移，可能需要分批并错开迁移时间以适应团队的时间表，从而延长迁移工作周期。

## 确定 GitHub 组织结构

接下来，规划您将在GitHub中创建的组织结构。 ADO 和 GitHub 组织企业工作的方式不同。

* ADO：组织>团队项目>存储库
* GitHub：企业>组织>存储库

迁移到 GitHub后，您应该只拥有一个企业帐户和作为同一企业的少数附属组织。 ADO 中的每个组织都应该对应于在 GitHub 上的一个组织。

> \[!NOTE] 团队项目的概念（用于对 ADO 中的存储库进行分组）不存在。GitHub 建议不要在GitHub上为ADO上的每个团队项目创建组织，因为这可能会导致每个组织中出现未分组的存储库列表。 但你可以创建团队来管理对存储库组的访问。

如果要将迁移工作分解成批，新结构可以帮助你确定它们。 如果 ADO 中有多个组织，并且每个组织的存储库都是合理大小的批次，请考虑按组织进行批处理。

1. 确定新的组织结构。
2. 决定是否需要将迁移工作分解成更小的批次。
3. 如果需要，请决定要如何分解迁移。

## 配置存储库权限

由于权限的工作方式 GitHub 不同于 ADO， GitHub Enterprise Importer 因此不会尝试从 ADO 迁移存储库权限。

使用 ADO2GH CLI 时，GitHub Enterprise Importer 将在 GitHub 为 ADO 中的每个团队项目创建两个团队。 每个团队被授予面向所有源自团队项目的存储库的不同级别的访问权限。

| 团队               | 对已迁移的存储库的访问 |
| ---------------- | ----------- |
| 团队-项目-维护者        | 维护者         |
| TEAM-PROJECT-管理员 | 管理员         |

若要授予面向迁移存储库的访问权限，可以将人员添加到这些团队。 可以在 GitHub 上手动执行此操作，或者在迁移过程中选择将团队链接到 Azure Active Directory （AAD） 组，方法是在 AAD 中管理组成员身份。 有关手动管理团队成员身份的详细信息，请参阅 [添加组织成员到团队](/zh/organizations/organizing-members-into-teams/adding-organization-members-to-a-team)。