关于 GitHub Enterprise Importer 的迁移支持
GitHub Enterprise Importer 可以从任何受支持的迁移源迁移到 GitHub Enterprise Cloud。 每个迁移中包含的数据取决于源。
GitHub Enterprise Importer 支持从以下源迁移到 GitHub Enterprise Cloud。
- Azure DevOps (ADO) Cloud
- Bitbucket Server 和 Bitbucket Data Center 5.14 或更高版本
- GitHub.com
- GitHub Enterprise Server (GHES) 3.4.1 或更高版本
在 beta 版本期间，Importer 存在适用于所有源的已知限制。
Azure DevOps 迁移支持
如果迁移源是 Azure DevOps，则可以迁移存储库。
只能使用 GitHub Enterprise Importer 从 Azure DevOps Cloud 迁移，而不能从 Azure DevOps Server 迁移。 如果当前使用 Azure DevOps Server，并且想要迁移到 GitHub，可以先迁移到 Azure DevOps Cloud。 有关详细信息，请参阅 Azure 站点上的迁移到 Azure DevOps。
目前仅支持将以下存储库数据从 Azure DevOps 迁移到 GitHub Enterprise Cloud。
- Git 源（包括提交历史记录）
- 拉取请求
- 拉取请求的用户历史记录
- 拉取请求上的工作项链接
- 拉取请求上的附件
- 存储库的分支保护（不包括用户范围的分支保护）
如果要将 Azure Pipelines 迁移到 GitHub Actions，请联系 GitHub 帐户管理员。
Bitbucket Server 迁移支持
仅 Bitbucket Server 或 Bitbucket 数据中心 5.14+ 或更高版本支持从 Bitbucket Server 进行迁移。
如果迁移源是 Bitbucket Server，则可以迁移存储库。 目前仅支持将以下存储库数据从 Bitbucket Server 迁移到 GitHub Enterprise Cloud。
- Git 源（包括提交历史记录）
- 拉取请求（包括注释、拉取请求审查、文件和行级别的拉取请求审查注释、所需的审阅者和附件）
目前，不会迁移以下数据。
- 用户拥有的个人存储库
- 分支权限
- 提交注释
- 存储库设置
GitHub Enterprise Importer 不会从 Bitbucket Server 迁移 CI 管道。
GitHub.com 迁移支持
如果迁移源为 GitHub.com，则可以迁移单个存储库或整个组织。
迁移组织时，目标企业帐户中会创建一个新组织。 然后，以下数据将迁移到新组织。
- Teams
- 存储库
- 团队对存储库的访问权限
- 成员特权
- 组织级 Webhook
- 在组织中创建的新存储库的默认分支名称
所有存储库都以专用可见性进行迁移。 如果要将存储库的可见性设置为公共或内部，可以在迁移后使用 UI 或 API 进行设置。
团队成员身份不会迁移。 迁移后，需要将成员添加到已迁移的团队。 有关详细信息，请参阅“使用 GitHub Enterprise Importer 在 GitHub 产品之间迁移”。
注意：对团队的引用（例如 @octo-org/octo-team）不会在组织迁移的过程中更新。 这可能会导致目标组织出现问题，例如 CODEOWNERS 文件未按预期工作。 有关如何预防并解决这些问题的详细信息，请参阅“使用 GitHub Enterprise Importer 排查迁移问题”。
直接或在组织迁移过程中迁移存储库时，只会迁移以下数据。
- Git 源（包括提交历史记录）
- 拉取请求
- 问题
- 里程碑
- Wiki
- 存储库级别的项目（经典）
- GitHub Actions 工作流程
- 提交注释
- 活动 Webhook
- 仓库主题
- 存储库设置
- 分支保护（请参阅“分支保护”了解更多详细信息）
- GitHub Pages 设置
- 自动链接引用
- GitHub Advanced Security 设置
- 拉取请求设置
- 自动删除头部分支
- 允许自动合并
- 允许合并提交（提交消息设置重置为默认消息）
- 允许 squash 合并（提交消息设置重置为默认消息）
- 允许变基合并
- 发布（每个存储库最多 10 GB）
- 上述数据的用户历史记录
目前，以下数据未迁移。
- 任何 Projects（新项目体验）
- Code scanning 结果
- 提交状态检查
- Dependabot 警报
- Dependabot 机密
- 存储库级别的讨论
- 编辑议题注释和拉取请求注释的历史记录
- 存储库之间的分支关系（请参阅“关于分叉”）
- GitHub Actions 机密、变量、环境、自托管运行器、大型运行器 或工作流运行历史记录
- GitHub Codespaces 机密
- GitHub 应用和 GitHub 应用安装
- Git LFS 对象和大型二进制文件（仍然支持使用 Git LFS 的存储库，请参阅“GitHub Enterprise Importer 的限制”）
- GitHub Packages 中的包
- 组织级别的项目（经典）
- 不同存储库中拉取请求与问题之间的引用（请参阅“自动链接引用和 URL”）
- secret scanning 结果的修正状态
- 用户帐户拥有的存储库
- 存储库属性（公共 beta 版）
- 存储库星级
- 存储库观察程序
- 规则集
- 标记保护规则
- 用户配置文件、SSH 密钥、签名密钥或personal access tokens
- Webhook 密码
- 用户对存储库的访问权限
直接迁移存储库时，团队和团队对存储库的访问权限不会迁移。
分支保护
分支保护将一组指定的规则应用于特定分支名称或分支名称模式。 有关详细信息，请参阅“关于受保护分支”。
始终都会迁移分支保护，但不会迁移某些规则。 以下分支保护规则不会迁移。
- 允许特定参与者绕过所需的拉取请求
- 需要审批最近的推送
- 在合并前要求部署成功
- 锁定分支
- 限制创建匹配分支的推送
- 允许强制推送
还存在下列限制：
- 如果分支保护规则可以选择性地用于指定不受该规则限制的人员、团队或应用（例如“限制可以关闭拉取请求评审的人员”），则不会迁移这些例外情况。
- 如果在“指定可以进行强制推送的人员”模式下启用了“允许强制推送”规则，则不会迁移该规则。
GitHub Enterprise Server 迁移支持
如果迁移源为 GitHub Enterprise Server，则可以迁移存储库。
要从 GitHub Enterprise Server (GHES) 迁移，必须有 GHES 3.4.1 或更高版本。
| 项 | GHES 3.4.1+ | GHES 3.5.0+ |
|---|---|---|
| Git 源（包括提交历史记录） | X | X |
| 拉取请求 | X | X |
| 问题 | X | X |
| 里程碑 | X | X |
| Wiki | X | X |
| 存储库级别的项目（经典） | X | X |
| GitHub Actions 工作流程 | X | X |
| 提交注释 | X | X |
| 活动 Webhook | X | X |
| 分支保护 | X | X |
| GitHub Pages 设置 | X | X |
| 上述数据的用户历史记录 | X | X |
| 版本 | ||
| X |
根据 GHES 版本，每个存储库适用不同的大小限制。
| 限制 | GHES <3.8.0 | GHES 3.8.0+ |
|---|---|---|
| Git 源 | 2GB | 10GB |
| Metadata | 2GB | 10GB |
目前，以下数据未迁移。
- 任何 Projects（新项目体验）
- Code scanning 结果
- 提交状态检查
- Dependabot 警报
- Dependabot 机密
- 存储库级别的讨论
- 编辑议题注释和拉取请求注释的历史记录
- 存储库之间的分支关系（请参阅“关于分叉”）
- GitHub Actions 机密、变量、环境、自托管运行器、大型运行器 或工作流运行历史记录
- GitHub Codespaces 机密
- GitHub 应用和 GitHub 应用安装
- Git LFS 对象和大型二进制文件（仍然支持使用 Git LFS 的存储库，请参阅“GitHub Enterprise Importer 的限制”）
- GitHub Packages 中的包
- 组织级别的项目（经典）
- 不同存储库中拉取请求与问题之间的引用（请参阅“自动链接引用和 URL”）
- secret scanning 结果的修正状态
- 用户帐户拥有的存储库
- 存储库属性（公共 beta 版）
- 存储库星级
- 存储库观察程序
- 规则集
- 标记保护规则
- 用户配置文件、SSH 密钥、签名密钥或personal access tokens
- Webhook 密码
- Teams
- 用户或团队对存储库的访问权限
- 拉取请求的存储库设置
限制
GitHub Enterprise Importer 可以迁移的内容存在限制。 有些是由于 GitHub.com 的限制，而另一些是由于 GitHub Enterprise Importer 本身的限制。
GitHub.com 的限制
- 单个 Git 提交的大小限制为 2 GB：Git 存储库中的单个提交不能大于 2 GB。 如果有任何提交大于 2 GB，则需要将其拆分为较小的提交，使每个提交的大小不超过 2 GB。
- Git 引用的限制为 255 字节：单个 Git 引用（通常称为“ref”）的名称不能大于 255 字节。 通常，这意味着引用的长度不能超过 255 个字符，但任何非 ASCII 字符（如表情符号）都可能占用多个字节。 如果任何 Git 引用太长，将返回明确的错误消息。
- 文件大小限制为 100 MB：Git 存储库中的单个文件不能大于 100 MB。 请考虑使用 Git LFS 来存储大型文件。 有关详细信息，请参阅“管理大型文件”。
GitHub Enterprise Importer 的限制
- Git 存储库的大小限制为 10 GB：此限制仅适用于源代码。 要检查存储库的大小，请使用 git-sizer 工具，并检查 Blob 的总大小。
- 元数据的限制为 10 GB：Importer 无法迁移元数据超过 10 GB 的存储库。 元数据包括问题、拉取请求、发布和附件。 在大多数情况下，大型元数据是由附加到发布的二进制资产引起的。 可以使用
migrate-repo命令的--skip-releases标志从迁移中排除发布，然后在迁移后手动移动发布。 - Git LFS 对象未迁移：Importer 可以迁移使用 Git LFS 的存储库，但不会迁移 LFS 对象本身。 迁移完成后，可以将其作为后续任务推送到迁移目标。 有关详细信息，请参阅“复制仓库”。
- 所需后续任务：在 GitHub 产品之间迁移时，某些设置不会迁移，必须在新存储库中重新配置。 有关每次迁移后需要完成的后续任务的列表，请参阅“使用 GitHub Enterprise Importer 在 GitHub 产品之间迁移”。
- 延迟的代码搜索功能：迁移存储库后，重新编制搜索索引可能需要几个小时，在重新编制索引完成前，代码搜索可能会返回意外的结果。
- 为组织配置的规则集可能会导致迁移失败：例如，如果配置的规则要求提交作者的电子邮件地址以
@monalisa.cat结尾，而要迁移的存储库包含不符合此规则的提交，则迁移将失败。 有关规则集的详细信息，请参阅“关于规则集”。