关于 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 上采用某些功能,例如 Enterprise Managed Users 或新的计费模式
- 通过从 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,则这两者的使用量不会包含在单个计划中。
-
如果要迁移到 Enterprise Managed Users:你将需要与标识提供者集成以管理用户帐户****。 在开始之前,请检查标识提供者的支持级别。 请参阅“关于 Enterprise Managed Users”。
-
如果要从 GitHub Enterprise Server 迁移:请注意,GitHub 会将速率限制应用于某些操作,默认情况下将在 GitHub Enterprise Server 上禁用这些操作****。 请参阅“REST API 的速率限制”。
-
如果要迁移到 具有数据驻留的 GitHub Enterprise Cloud:请注意,某些功能不可用,并且某些功能需要不同或额外的配置****。 请参阅“具有数据驻留的 GitHub Enterprise Cloud 的功能概述”。
从 GitHub Enterprise Server 迁移的数据
Warning
Wikis 迁移当前不可用。 解决方法是可以手动迁移:
git clone --mirror OLD-REPOSITORY-URL cd OLD-REPOSITORY-NAME git remote add new-origin NEW-REPOSITORY-URL git push new-origin --mirror
git clone --mirror OLD-REPOSITORY-URL
cd OLD-REPOSITORY-NAME
git remote add new-origin NEW-REPOSITORY-URL
git push new-origin --mirror
要从 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.0+ |
---|---|---|
Git 源 | 2GB | 10GB |
Metadata | 2GB | 10GB |
不迁移的数据
目前,不会迁移以下数据。
- 审核日志
- Code scanning 结果
- 提交状态检查
- Dependabot 警报
- Dependabot 机密
- 存储库级别的讨论
- 编辑议题注释和拉取请求注释的历史记录
- 存储库之间的分支关系(请参阅“关于分叉”)
- GitHub Actions 机密、变量、环境、自托管运行器、大型运行器 或工作流运行历史记录
- GitHub 应用和 GitHub 应用安装
- Git LFS 对象和大型二进制文件(仍然支持使用 Git LFS 的存储库,请参阅“GitHub Enterprise Importer 的限制”)
- GitHub Packages 中的包
- 组织级别的项目(经典)
- Projects(新项目体验)
- 不同存储库中拉取请求与问题之间的引用(请参阅“自动链接引用和 URL”)
- secret scanning 结果的修正状态
- 用户帐户拥有的存储库
- 存储库属性
- 存储库星级
- 存储库观察程序
- 规则集
- 标记保护规则
- 用户配置文件、SSH 密钥、签名密钥或personal access tokens
- Webhook 密码
- Teams
- 用户或团队对存储库的访问权限
- 拉取请求的存储库设置
分支保护
分支保护将一组指定的规则应用于特定分支名称或分支名称模式。 有关详细信息,请参阅“关于受保护分支”。
始终都会迁移分支保护,但不会迁移某些规则。 以下分支保护规则不会迁移。
- 允许特定参与者绕过所需的拉取请求
- 需要审批最近的推送
- 在合并前要求部署成功
- 锁定分支
- 限制创建匹配分支的推送
- 允许强制推送
还存在下列限制:
- 如果分支保护规则可以选择性地用于指定不受该规则限制的人员、团队或应用(例如“限制可以关闭拉取请求评审的人员”),则不会迁移这些例外情况。
- 如果在“指定可以进行强制推送的人员”模式下启用了“允许强制推送”规则,则不会迁移该规则。
从 GitHub.com 迁移的数据
如果迁移源为 GitHub.com 上的帐户,可以在组织之间迁移单个存储库,或在企业之间迁移整个组织。
组织的迁移数据
迁移组织时,目标企业帐户中会创建一个新组织。 然后,以下数据将迁移到新组织。
- Teams
- 存储库
- 团队对存储库的访问权限
- 成员特权
- 组织级别的 Webhook(必须在迁移后重新启用,请参阅启用 Webhook)
- 在组织中创建的新存储库的默认分支名称
所有存储库都以专用可见性进行迁移。 如果要将存储库的可见性设置为公共或内部,可以在迁移后使用 UI 或 API 进行设置。
团队成员身份不会迁移。 迁移后,需要将成员添加到已迁移的团队。 有关详细信息,请参阅“在 GitHub 产品之间迁移的概述”。
Note
对团队的引用(例如 @octo-org/octo-team
)不会在组织迁移的过程中更新。 这可能会导致目标组织出现问题,例如 CODEOWNERS
文件未按预期工作。 有关如何预防并解决这些问题的详细信息,请参阅“使用 GitHub Enterprise Importer 排查迁移问题”。
存储库的迁移数据
直接或在组织迁移过程中迁移存储库时,只会迁移以下数据。
- Git 源(包括提交历史记录)
- 拉取请求
- 问题
- 里程碑
- Wiki(不包括附件)
- GitHub Actions 工作流程
- 提交注释
- 活动的 Webhook(必须在迁移后重新启用,请参阅“启用 Webhook”)
- 仓库主题
- 存储库设置
- 分支保护(请参阅分支保护,了解更多详细信息)
- GitHub Pages 设置
- 自动链接引用
- GitHub Advanced Security 设置
- 拉取请求设置
- 自动删除头部分支
- 允许自动合并
- 允许合并提交(提交消息设置重置为默认消息)
- 允许 squash 合并(提交消息设置重置为默认消息)
- 允许变基合并
- 发布(每个存储库最多 10 GB)
- 上述数据的用户历史记录
- 附件(请参阅“附加文件”)
不迁移的数据
目前,不会迁移以下数据。
- Codespaces 机密 * 审核日志
- Code scanning 结果
- 提交状态检查
- Dependabot 警报
- Dependabot 机密
- 存储库级别的讨论
- 编辑议题注释和拉取请求注释的历史记录
- 存储库之间的分支关系(请参阅“关于分叉”)
- GitHub Actions 机密、变量、环境、自托管运行器、大型运行器 或工作流运行历史记录
- GitHub 应用和 GitHub 应用安装
- Git LFS 对象和大型二进制文件(仍然支持使用 Git LFS 的存储库,请参阅“GitHub Enterprise Importer 的限制”)
- GitHub Packages 中的包
- 组织级别的项目(经典)
- Projects(新项目体验)
- 不同存储库中拉取请求与问题之间的引用(请参阅“自动链接引用和 URL”)
- secret scanning 结果的修正状态
- 用户帐户拥有的存储库
- 存储库属性
- 存储库星级
- 存储库观察程序
- 规则集
- 标记保护规则
- 用户配置文件、SSH 密钥、签名密钥或personal access tokens
- Webhook 密码
- 用户对存储库的访问权限
直接迁移存储库时,团队和团队对存储库的访问权限不会迁移。
分支保护
分支保护将一组指定的规则应用于特定分支名称或分支名称模式。 有关详细信息,请参阅“关于受保护分支”。
始终都会迁移分支保护,但不会迁移某些规则。 以下分支保护规则不会迁移。
- 允许特定参与者绕过所需的拉取请求
- 需要审批最近的推送
- 在合并前要求部署成功
- 锁定分支
- 限制创建匹配分支的推送
- 允许强制推送
还存在下列限制:
- 如果分支保护规则可以选择性地用于指定不受该规则限制的人员、团队或应用(例如“限制可以关闭拉取请求评审的人员”),则不会迁移这些例外情况。
- 如果在“指定可以进行强制推送的人员”模式下启用了“允许强制推送”规则,则不会迁移该规则。
迁移数据的限制
GitHub Enterprise Importer 可以迁移的内容存在限制。 有些是由于 GitHub 的限制,而另一些是由于 GitHub Enterprise Importer 本身的限制。
GitHub 的限制
- 单个 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 总大小。 git-sizer 工具还有助于识别与大型文件、blob 大小、提交大小和可能影响迁移的树计数相关的潜在问题。
- 元数据的限制为 10 GB:Importer 无法迁移元数据超过 10 GB 的存储库。 元数据包括问题、拉取请求、发布和附件。 在大多数情况下,大型元数据是由附加到发布的二进制资产引起的。 可以使用
migrate-repo
命令的--skip-releases
标志从迁移中排除发布,然后在迁移后手动移动发布。 - Git LFS 对象未迁移:Importer 可以迁移使用 Git LFS 的存储库,但不会迁移 LFS 对象本身。 迁移完成后,可以将其作为后续任务推送到迁移目标。 有关详细信息,请参阅“复制仓库”。
- 所需后续任务:在 GitHub 产品之间迁移时,某些设置不会迁移,必须在新存储库中重新配置。 有关每次迁移后需要完成的后续任务的列表,请参阅“在 GitHub 产品之间迁移的概述”。
- 延迟的代码搜索功能:迁移存储库后,重新编制搜索索引可能需要几个小时,在重新编制索引完成前,代码搜索可能会返回意外的结果。
- 为组织配置的规则集可能会导致迁移失败:例如,如果配置的规则要求提交作者的电子邮件地址以
@monalisa.cat
结尾,而要迁移的存储库包含不符合此规则的提交,则迁移将失败。 有关规则集的详细信息,请参阅“关于规则集”。 - 模特内容可能不可搜索:模特是与导入内容(如问题、拉取请求、注释等)关联的占位符用户。 搜索与模特关联的内容(如已分配的问题)时,可能找不到问题。 回收模特后,通过新所有者可找到内容。 有关详细信息,请参阅“回收 GitHub Enterprise Importer 的模型”。
入门
在 GitHub 产品之间迁移之前,应规划出如何开展迁移。 迁移数据之前,需要选择开展迁移的人。 必须向该人员授予迁移源和迁移目的地的所需访问权限。 我们还建议先开展测试迁移。
有关完整迁移过程的概述,请参阅“在 GitHub 产品之间迁移的概述”。