此版本的 GitHub Enterprise Server 已于以下日期停止服务 2024-09-25. 即使针对重大安全问题，也不会发布补丁。 为了获得更好的性能、更高的安全性和新功能，请升级到最新版本的 GitHub Enterprise。 如需升级帮助，请联系 GitHub Enterprise 支持。

关于 GitHub 产品之间的迁移

了解 GitHub Enterprise Importer 可以在 GitHub 产品之间迁移的数据。

本文内容

关于 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 迁移当前不可用。 解决方法是可以手动迁移：

Shell
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.0GHES 3.8.0+
Git 源2GB10GB
Metadata2GB10GB

不迁移的数据

目前，不会迁移以下数据。

  • 审核日志
  • 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 产品之间迁移的概述”。