规划从 GitLab 迁移到 GitHub

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

Run your migration

7 篇中的第 2 篇
下一步:管理从 GitLab 迁移到 GitHub的访问

在本文中

确定需要迁移的内容量

首先找出时间线，因为它基本上将塑造你的方法。 若要确定时间线，第一步是获取需迁移内容的清单。

  • 存储库数（项目）
  • 合并请求数

注意

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

我们建议在inventory-report中使用GL2GH extension of the GitHub CLI命令。 此命令连接到 GitLab API 并创建两个 CSV 文件。 groups.csv 列出 GitLab 组，并 projects.csv 列出项目，包括合并请求数。

若要生成 CSV 文件，请使用以下命令，将替换为 GITLAB_SERVER_URL GitLab 服务器的 URL（例如 https://gitlab.com），以及 YOUR_GITLAB_GROUP 要报告的组。 若要报告可以访问的所有项目，请省略 --gitlab-group。 对于所有可用选项，请运行 gh gl2gh inventory-report --help。

Shell
gh gl2gh inventory-report --gitlab-server-url GITLAB_SERVER_URL --gitlab-group YOUR_GITLAB_GROUP

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

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

确定 GitHub 组织结构

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

  • GitLab：实例>组>子组（最多可以嵌套 20 个级别）>项目（存储库）
  • GitHub：企业>组织>存储库

迁移到 GitHub后，你应只有一个企业帐户和一些由该企业拥有的组织。 GitLab 中的每个顶级组通常对应于一个组织。GitHub 有关要创建的组织数的指导，请参阅 在企业中组织工作的最佳做法。

注意

GitHub 不具有 GitLab 嵌套子组的等效项。 我们不建议为每个子组创建组织 GitHub ，因为这可能会导致每个组织中未分组的存储库列表。 相反，可以通过创建团队来管理对存储库组的访问权限。

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

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

配置存储库权限

由于权限的工作方式 GitHub 不同于 GitLab， GitHub Enterprise Importer 因此不会从 GitLab 迁移存储库权限、组设置或组成员身份。

在 GitLab 中，成员在组、子组或项目级别被授予角色（如 Guest、Reporter、Developer、Maintainer 或 Owner），这些角色继承到层次结构中。 这些角色不会直接 GitHub映射到，因此在迁移后需要重新创建访问权限。

若要让用户能够访问迁移的存储库 GitHub，我们建议创建团队并向每个团队授予对相关组织和存储库的适当访问权限级别。 然后，可以将人员添加到这些团队。 请参阅“企业中的团队”。