关于GitHub产品间的迁移

了解GitHub企业导入器可以在GitHub产品之间迁移哪些数据。

本文内容

关于GitHub产品间的迁移

使用GitHub企业导入器，您可以将数据从GitHub企业服务器迁移到GitHub企业云，或将数据从GitHub.com迁移到GitHub企业云上的另一个帐户。

例如，GitHub企业导入器可以帮助您的公司：

  • 通过将您的企业迁移到GHE.com，采用具有数据驻留的GitHub企业云。
  • 通过在GitHub.com上的企业之间迁移，采用GitHub.com上的某些功能，例如企业管理用户或新的计费模式。
  • 通过从GitHub企业服务器迁移到GitHub企业云，受益于简化的管理和新功能。

如果您的迁移源是GitHub.com上的帐户，您可以迁移组织间的单个仓库，或迁移企业间的整个组织。如果您的迁移源是GitHub企业服务器，您可以迁移单个仓库。

GitHub企业导入器迁移的数据取决于迁移的来源以及您迁移的是仓库还是组织。

迁移到GitHub企业云的注意事项

在使用GitHub企业导入器之前，请了解以下注意事项：

  • 如果您**已经使用GitHub企业云**：GitHub企业计划允许您部署一个GitHub企业云。

    例如，如果您已经使用GitHub.com，并且还想从GitHub企业服务器迁移到GHE.com，则您对两者的使用都不会包含在一个计划中。

  • 如果您**迁移到企业管理用户**：您需要与身份提供商集成以管理用户帐户。在开始之前，请检查您身份提供商的支持级别。请参阅“关于企业管理用户”。

  • 如果您**从GitHub企业服务器迁移**：请注意，GitHub会对某些操作应用速率限制，这些限制在GitHub企业服务器上默认情况下是禁用的。请参阅“REST API 的速率限制”。

  • 如果您**迁移到具有数据驻留的GitHub企业云**：请注意，某些功能不可用，某些功能需要不同的或额外的配置。请参阅“具有数据驻留的GitHub企业云的功能概述”。

从GitHub企业服务器迁移的数据

警告

Wiki迁移目前不可用。作为解决方法，您可以手动迁移。

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企业服务器 (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
元数据2GB10GB

未迁移的数据

目前，以下数据**未**迁移。

  • 代码扫描结果
  • 提交状态检查
  • Dependabot 警报
  • Dependabot 密钥
  • 仓库级别的讨论
  • 问题评论和拉取请求评论的编辑历史记录
  • 仓库之间的分支关系（请参阅“关于分支”）
  • GitHub Actions 密钥、变量、环境、自托管运行器、大型运行器或工作流程运行历史记录
  • GitHub Apps 和 GitHub App 安装
  • Git LFS 对象和大型二进制文件（仍然支持使用 Git LFS 的仓库，请参阅“GitHub 企业导入器的限制”）
  • GitHub Packages 中的软件包
  • 组织级别的项目（经典项目）
  • 项目（新的项目体验）
  • 不同仓库中拉取请求和问题之间的引用（请参阅“自动链接的引用和URL”）
  • 密钥扫描结果的修复状态
  • 用户帐户拥有的仓库
  • 仓库属性
  • 仓库星标
  • 仓库关注者
  • 规则集
  • 标签保护规则
  • 用户资料、SSH 密钥、签名密钥或个人访问令牌
  • Webhook 密钥
  • 团队
  • 用户或团队对仓库的访问权限
  • 拉取请求的仓库设置

分支保护

分支保护会将指定的一组规则应用于特定的分支名称或分支名称模式。更多信息，请参阅“关于受保护分支”。

分支保护将始终被迁移，但某些规则不会被迁移。以下分支保护规则不会被迁移。

  • 允许特定参与者绕过必需的拉取请求
  • 要求批准最新的推送
  • 要求部署成功后才能合并
  • 锁定分支
  • 限制创建匹配分支的推送
  • 允许强制推送

还适用以下限制

  • 如果分支保护规则可以选择允许您指定免受规则影响的人员、团队或应用（例如，“限制可以驳回拉取请求评审的人员”），则这些例外情况将不会被迁移。
  • 如果在“指定可以强制推送的人员”模式下启用了“允许强制推送”规则，则该规则将不会被迁移。

从 GitHub.com 迁移的数据

如果您的迁移源是 GitHub.com 上的帐户，您可以迁移组织之间的单个仓库，或迁移企业之间的整个组织。

组织的迁移数据

迁移组织时，会在目标企业帐户中创建一个新的组织。然后，将以下数据迁移到新组织。

  • 团队
  • 仓库
  • 团队对仓库的访问权限
  • 成员权限
  • 组织级 Webhook（迁移后必须重新启用，请参阅“启用 Webhook”）
  • 在组织中创建的新仓库的默认分支名称

所有仓库都以私有可见性迁移。如果要将仓库的可见性设置为公开或内部，可以在迁移后使用 UI 或 API 执行此操作。

团队成员身份**不会**迁移。迁移后，您需要将成员添加到迁移的团队。更多信息，请参阅“GitHub 产品之间迁移概述”。

注意

对团队的引用（例如 @octo-org/octo-team）**不会**作为组织迁移的一部分进行更新。这可能会导致目标组织出现问题，例如 CODEOWNERS 文件无法按预期工作。有关如何预防和解决这些问题的更多信息，请参阅“使用 GitHub Enterprise Importer 疑难解答迁移”。

仓库的迁移数据

直接迁移仓库或作为组织迁移的一部分迁移仓库时，只会迁移以下数据。

  • Git 源代码（包括提交历史）
  • 拉取请求
  • 问题
  • 里程碑
  • Wiki（不包括附件）
  • GitHub Actions 工作流程
  • 提交评论
  • 活动 Webhook（迁移后必须重新启用，请参阅“启用 Webhook”）
  • 仓库主题
  • 仓库设置
    • 分支保护（更多详细信息，请参阅“分支保护”）
    • GitHub Pages 设置
    • 自动链接引用
    • GitHub 高级安全设置
    • 拉取请求设置
      • 自动删除头部分支
      • 允许自动合并
      • 允许合并提交（提交消息设置将重置为默认消息）
      • 允许合并压缩（提交消息设置将重置为默认消息）
      • 允许变基合并
  • 发布（每个仓库最多 10 GB）
  • 上述数据的用户历史记录
  • 附件（请参阅“附加文件”）

未迁移的数据

目前，以下数据**未**迁移。

  • Codespaces 密钥
  • 代码扫描结果
  • 提交状态检查
  • Dependabot 警报
  • Dependabot 密钥
  • 仓库级别的讨论
  • 问题评论和拉取请求评论的编辑历史记录
  • 仓库之间的分支关系（请参阅“关于分支”）
  • GitHub Actions 密钥、变量、环境、自托管运行器、大型运行器或工作流程运行历史记录
  • GitHub Apps 和 GitHub App 安装
  • Git LFS 对象和大型二进制文件（仍然支持使用 Git LFS 的仓库，请参阅“GitHub 企业导入器的限制”）
  • GitHub Packages 中的软件包
  • 组织级别的项目（经典项目）
  • 项目（新的项目体验）
  • 不同仓库中拉取请求和问题之间的引用（请参阅“自动链接的引用和URL”）
  • 密钥扫描结果的修复状态
  • 用户帐户拥有的仓库
  • 仓库属性
  • 仓库星标
  • 仓库关注者
  • 规则集
  • 标签保护规则
  • 用户资料、SSH 密钥、签名密钥或个人访问令牌
  • Webhook 密钥
  • 用户对仓库的访问权限

直接迁移仓库时，不会迁移团队和团队对仓库的访问权限。

分支保护

分支保护会将指定的一组规则应用于特定的分支名称或分支名称模式。更多信息，请参阅“关于受保护分支”。

分支保护将始终被迁移，但某些规则不会被迁移。以下分支保护规则不会被迁移。

  • 允许特定参与者绕过必需的拉取请求
  • 要求批准最新的推送
  • 要求部署成功后才能合并
  • 锁定分支
  • 限制创建匹配分支的推送
  • 允许强制推送

还适用以下限制

  • 如果分支保护规则可以选择允许您指定免受规则影响的人员、团队或应用（例如，“限制可以驳回拉取请求评审的人员”），则这些例外情况将不会被迁移。
  • 如果在“指定可以强制推送的人员”模式下启用了“允许强制推送”规则，则该规则将不会被迁移。

迁移数据的限制

GitHub Enterprise Importer 可以迁移的内容有限制。有些是由于 GitHub 的限制，而有些是由于 GitHub Enterprise Importer 本身的限制。

GitHub 的限制

  • **单个 Git 提交的 2 GB 大小限制：**Git 仓库中的任何单个提交都不能大于 2 GB。如果您的任何提交都大于 2 GB，则需要将提交拆分为每个大小均为 2 GB 或更小的较小提交。
  • **Git 引用的 255 字节限制：**任何单个 Git 引用（通常称为“引用”）的名称都不能大于 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 产品之间迁移概述”。