关于 GitHub 产品之间的迁移
使用 GitHub Enterprise Importer，您可以将数据从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud，或将数据从 GitHub.com 迁移到 GitHub Enterprise Cloud 上的另一个账户。
例如，GitHub Enterprise Importer 可以帮助您的公司
- 通过将企业迁移到 GHE.com，实现数据驻留并采用 GitHub Enterprise Cloud
- 通过在 GitHub.com 上的企业之间迁移，采用 GitHub.com 的特定功能，例如企业托管用户或新的计费模式
- 通过从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud，受益于简化的管理和新功能
如果您的迁移来源是 GitHub.com 上的账户，您可以在组织之间迁移单个仓库，或在企业之间迁移整个组织。如果迁移来源是 GitHub Enterprise Server，您只能迁移单个仓库。
GitHub Enterprise Importer 迁移的数据取决于迁移的来源以及是迁移仓库还是组织。
迁移到 GitHub Enterprise Cloud 的注意事项
在使用 GitHub Enterprise Importer 之前，请了解以下注意事项
-
如果您已经使用 GitHub Enterprise Cloud：GitHub Enterprise 计划仅授予您一次 GitHub Enterprise Cloud 部署权限。
例如，如果您已经使用 GitHub.com，同时还想将 GitHub Enterprise Server 迁移到 GHE.com，则两者的使用将不在同一计划覆盖范围内。
-
如果您迁移到企业托管用户：您需要与身份提供商集成以管理用户账户。在开始之前检查身份提供商的支持等级。参见关于企业托管用户。
-
如果您从 GitHub Enterprise Server 迁移：请注意，GitHub 对某些操作实施速率限制，而这些限制在 GitHub Enterprise Server 上默认是关闭的。参见REST API 的速率限制。
-
如果您迁移到具备数据驻留的 GitHub Enterprise Cloud：请注意，某些功能不可用，部分功能需要不同或额外的配置。参见具备数据驻留的 GitHub Enterprise Cloud 功能概览。
从 GitHub Enterprise Server 迁移的数据
要从 GitHub Enterprise Server（GHES）进行迁移，您必须使用 GHES 3.4.1 或更高版本。迁移的数据取决于您使用的版本。
| 项目 | GHES 3.4.1+ | GHES 3.5.0+ |
|---|---|---|
| Git 源代码（包括提交历史） | ||
| 拉取请求 | ||
| 议题 | ||
| 里程碑 | ||
| Wiki | ||
| GitHub Actions 工作流 | ||
| 提交评论 | ||
| Webhook（迁移后必须重新启用，参见启用 Webhook） | ||
| 分支保护 | ||
| GitHub Pages 设置 | ||
| 上述数据的用户历史记录 | ||
| 附件（参见附加文件） | ||
| 发布 |
根据 GHES 版本，对压缩归档的每个仓库适用不同的大小限制。
| 限制项 | GHES <3.8.0 | GHES 3.8.x-3.11.x | GHES 3.12.x | GHES 3.13.0+ |
|---|---|---|---|---|
| Git 源 | 2GiB | 10GiB | 20GiB | 40GiB（公开预览） |
| 元数据 | 2GiB | 10GiB | 20GiB | 40GiB（公开预览） |
未迁移的数据
目前，以下数据不会被迁移。
- 审计日志
- 代码扫描结果
- Codespaces 机密
- 提交状态检查
- Dependabot 警报
- Dependabot 机密
- 仓库级别的讨论
- 议题评论和拉取请求评论的编辑历史
- 仓库之间的 Fork 关系（参见关于 Fork）
- GitHub Actions 机密、变量、环境、自托管运行器、更大的运行器、工作流产物或工作流运行历史
- GitHub 应用及其安装
- Git LFS 对象和大二进制文件（仍支持使用 Git LFS 的仓库，参见GitHub Enterprise Importer 的限制）
- 从提交指向已使用 rebase 合并的拉取请求的链接
- 在拉取请求、议题、发布和评论正文中提及的用户、团队和组织（保留最初提及的用户名）
- GitHub Packages 中的包
- 项目（新版项目体验）
- 不同仓库之间的拉取请求和议题的引用（参见自动链接引用和 URL）
- 机密扫描结果的修复状态
- 用户账户拥有的仓库
- 仓库活动订阅
- 仓库属性
- 仓库星标
- 仓库关注者
- 规则集
- 子议题（参见关于议题）
- 标签保护规则
- 用户对仓库的访问权限
- 用户的个人资料、SSH 密钥、签名密钥或个人访问令牌
- Webhook 机密
- Teams
- 用户或团队对仓库的访问权限
- 拉取请求的仓库设置
分支保护
分支保护对特定分支名称或分支名称模式应用一套指定规则。更多信息，请参见关于受保护分支。
分支保护始终会被迁移，但某些规则不会迁移。以下分支保护规则不会被迁移。
- 允许特定角色绕过强制拉取请求
- 要求对最近的推送进行批准
- 要求部署成功后才能合并
- 锁定分支
- 限制创建匹配分支的推送
- 允许强制推送
以下限制同样适用
- 如果分支保护规则可以选填指定免除该规则的人员、团队或应用，例如“限制谁可以驳回拉取请求审查”，这些例外将不会被迁移。
- 如果在“指定谁可以强制推送”模式下启用了“允许强制推送”规则，该规则将不会被迁移。
从 GitHub.com 迁移的数据
如果您的迁移来源是 GitHub.com 上的账户，您可以在组织之间迁移单个仓库，或在企业之间迁移整个组织。
组织迁移的数据
当您迁移组织时，会在目标企业账户内创建一个新组织。随后，以下数据会迁移到新组织。
- Teams
- 仓库
- 团队对仓库的访问权限
- 成员权限
- 组织级别的 Webhook（迁移后必须重新启用，参见启用 Webhook）
- 组织内新建仓库的默认分支名称
所有仓库均以私有可见性迁移。若想将仓库的可见性设为公开或内部，可在迁移后通过 UI 或 API 进行更改。
团队成员关系不会迁移。迁移后，您需要为迁移的团队添加成员。更多信息，请参见GitHub 产品之间迁移概览。
注意
对团队的引用，例如 @octo-org/octo-team，在组织迁移过程中不会更新。这可能导致目标组织出现问题，例如 CODEOWNERS 文件未按预期工作。有关如何防止和解决这些问题的更多信息，请参见使用 GitHub Enterprise Importer 排查迁移问题。
仓库迁移的数据
当您迁移仓库时，无论是直接迁移还是组织迁移的一部分，仅以下数据会被迁移。
- Git 源代码（包括提交历史）
- 拉取请求
- 议题
- 里程碑
- Wiki（不包括附件）
- GitHub Actions 工作流
- 提交评论
- 活动的 Webhook（迁移后必须重新启用，参见启用 Webhook）
- 仓库话题
- 仓库设置
- 分支保护（更多细节请参见分支保护）
- GitHub Pages 设置
- 自动链接引用
- 拉取请求设置
- 自动删除源分支
- 允许自动合并
- 允许合并提交（提交信息设置重置为默认信息）
- 允许 squash 合并（提交信息设置重置为默认信息）
- 允许 rebase 合并
- 发布（每个仓库最高 10 GiB）
- 上述数据的用户历史记录
- 附件（参见附加文件）
未迁移的数据
目前，以下数据不会被迁移。
- 审计日志
- 代码扫描结果
- Codespaces 机密
- 提交状态检查
- Dependabot 警报
- Dependabot 机密
- 仓库级别的讨论
- 议题评论和拉取请求评论的编辑历史
- 仓库之间的 Fork 关系（参见关于 Fork）
- GitHub Actions 机密、变量、环境、自托管运行器、更大的运行器、工作流产物或工作流运行历史
- GitHub 应用及其安装
- Git LFS 对象和大二进制文件（仍支持使用 Git LFS 的仓库，参见GitHub Enterprise Importer 的限制）
- 从提交指向已使用 rebase 合并的拉取请求的链接
- 在拉取请求、议题、发布和评论正文中提及的用户、团队和组织（保留最初提及的用户名）
- GitHub Packages 中的包
- 项目（新版项目体验）
- 不同仓库之间的拉取请求和议题的引用（参见自动链接引用和 URL）
- 机密扫描结果的修复状态
- 用户账户拥有的仓库
- 仓库活动订阅
- 仓库属性
- 仓库星标
- 仓库关注者
- 规则集
- 子议题（参见关于议题）
- 标签保护规则
- 用户对仓库的访问权限
- 用户的个人资料、SSH 密钥、签名密钥或个人访问令牌
- Webhook 机密
直接迁移仓库时，团队及其对仓库的访问权限不会被迁移。
分支保护
分支保护对特定分支名称或分支名称模式应用一套指定规则。更多信息，请参见关于受保护分支。
分支保护始终会被迁移，但某些规则不会迁移。以下分支保护规则不会被迁移。
- 允许特定角色绕过强制拉取请求
- 要求对最近的推送进行批准
- 要求部署成功后才能合并
- 锁定分支
- 限制创建匹配分支的推送
- 允许强制推送
以下限制同样适用
- 如果分支保护规则可以选填指定免除该规则的人员、团队或应用，例如“限制谁可以驳回拉取请求审查”，这些例外将不会被迁移。
- 如果在“指定谁可以强制推送”模式下启用了“允许强制推送”规则，该规则将不会被迁移。
迁移数据的限制
GitHub Enterprise Importer 能迁移的内容存在一定限制。部分限制来源于 GitHub 本身，另一些则是 GitHub Enterprise Importer 本身的限制。
GitHub 的限制
- 单个 Git 提交的 2 GiB 大小限制： 您的 Git 仓库中没有单个提交可以大于 2 GiB。如果有提交超过 2 GiB，您需要将其拆分为每个不超过 2 GiB 的更小提交。
- Git 引用的 255 字节限制：任何单个Git 引用（通常称为 “ref”）的名称不能超过 255 字节。通常这意味着引用名不能超过 255 个字符，但任何非ASCII字符（如表情符号）可能占用多个字节。如果您的 Git 引用过长，我们将返回明确的错误信息。
- 100 MiB 文件大小限制：迁移完成后，Git 仓库中的单个文件不能超过 100 MiB。迁移期间，此限制会提升至 400 MiB。请考虑使用 Git LFS 存储大文件。详情请参见管理大文件。
GitHub Enterprise Importer 的限制
- Git 仓库 40 GiB 大小限制（公开预览）：此限制仅适用于源代码。若要检查仓库压缩包是否超限，请使用 git-sizer 工具并查看输出中的总 Blob 大小。git-sizer 还能帮助识别大文件、Blob 大小、提交大小和树计数等可能影响迁移的问题。
- 元数据 40 GiB 限制（公开预览）：Importer 无法迁移元数据超过 40 GiB 的仓库。元数据包括议题、拉取请求、发布和附件。在大多数情况下，大量元数据是由发布中附带的二进制资产导致的。您可以使用
migrate-repo命令的--skip-releases标志在迁移时排除发布，随后手动迁移发布。 - 400 MiB 文件大小限制：使用 GitHub Enterprise Importer 迁移仓库时，Git 仓库中的单个文件不能超过 400 MiB。请考虑使用 Git LFS 存储大文件。详情请参见管理大文件。
- Git LFS 对象未迁移：Importer 可以迁移使用 Git LFS 的仓库，但 LFS 对象本身不会迁移。它们可以在迁移完成后作为后续任务推送到目标。更多信息请参见复制仓库。
- 需要后续任务：在 GitHub 产品之间迁移时，某些设置不会迁移，必须在新仓库中重新配置。有关每次迁移后需完成的后续任务列表，请参见GitHub 产品之间迁移概览。
- 代码搜索功能延迟： 在仓库迁移后，重新索引搜索索引可能需要数小时，在重新索引完成之前，代码搜索可能返回意外结果。
- 为组织配置的规则集可能导致迁移失败：例如，如果您配置了一个规则，要求提交作者的电子邮件地址必须以
@monalisa.cat结尾，而您迁移的仓库包含不符合此规则的提交，则迁移会失败。有关规则集的更多信息，请参见关于规则集。 - Mannequin 内容可能无法被搜索：Mannequin 是占位用户，用于关联导入的内容（如议题、拉取请求、评论等）。当您搜索与 mannequin 关联的内容，例如分配的议题时，可能找不到这些议题。一旦 mannequin 被重新认领，内容应能通过新拥有者被检索到。更多信息请参见为 GitHub Enterprise Importer 重新认领 mannequin。
入门指南
在 GitHub 产品之间迁移之前，您应规划迁移的执行方式。在迁移任何数据之前，需要指定人员负责迁移并为其授予源和目标两侧的必要访问权限。我们也建议先进行一次试运行迁移。
欲了解从头到尾的迁移流程概览，请参见GitHub 产品之间迁移概览。