关于使用 GitHub Enterprise Importer GitHub 产品之间的迁移

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

在本文中

关于 GitHub 产品之间的迁移

使用 GitHub Enterprise Importer，你可以将数据从 GitHub Enterprise Server 迁移到 GitHub Enterprise Cloud，或者将数据从 GitHub.com 迁移到 GitHub Enterprise Cloud 的另一个帐户。

如果迁移源是帐户 GitHub.com，则可以在组织之间迁移单个存储库，或者在企业之间迁移整个组织。 如果迁移源是 GitHub Enterprise Server，则可以迁移单个存储库。

迁移的数据 GitHub Enterprise Importer 取决于迁移的源以及是迁移存储库还是组织。

从 GitHub Enterprise Server 迁移的数据

若要从 GitHub Enterprise Server （GHES） 迁移，必须具有 GHES 3.4.1 或更高版本。 迁移的数据取决于所使用的版本。

项GHES 3.4.1+GHES 3.5.0+
Git 源（包括提交历史记录）
拉取请求
问题
里程碑
维基百科站点
          GitHub Actions 流程 | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  |

提交注释 | | | Webhook（必须在迁移后重新启用，请参阅启用 Webhook） | | | 分支保护 | | |

          GitHub Pages 设置 | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  | <svg version="1.1" width="16" height="16" viewBox="0 0 16 16" class="octicon octicon-check" aria-label="Can be migrated" role="img"><path d="M13.78 4.22a.75.75 0 0 1 0 1.06l-7.25 7.25a.75.75 0 0 1-1.06 0L2.22 9.28a.751.751 0 0 1 .018-1.042.751.751 0 0 1 1.042-.018L6 10.94l6.72-6.72a.75.75 0 0 1 1.06 0Z"></path></svg>  |

上述数据的用户历史记录 | | | 附件（请参阅“附加文件”） | | | 发布 | | |

每个存储库的不同大小限制适用于压缩存档，具体取决于 GHES 版本。

限制GHES <3.8.0GHES 3.8.x-3.11.xGHES 3.12.xGHES 3.13.0+
Git 源2 GiB10GiB20GiB40GiB（公共预览版）
元数据2 GiB10GiB20GiB40GiB（公共预览版）

不迁移的数据

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

  • 审核日志
  • Code scanning 结果
  • Codespaces 秘密
  • 提交状态检查
  • 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.com迁移过来的数据

如果迁移源是帐户 GitHub.com，则可以在组织之间迁移单个存储库，或者在企业之间迁移整个组织。

组织的迁移数据

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

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

所有存储库都以专用可见性进行迁移。 如果要将存储库的可见性设置为公共或内部，可以在迁移后使用 UI 或 API 进行设置。

团队成员身份不会迁移。 迁移后，需要将成员添加到已迁移的团队。 有关详细信息，请参阅“在 GitHub 产品之间迁移的概述”。

注意

对团队的引用（例如 @octo-org/octo-team）不会在组织迁移的过程中更新。 这可能会导致目标组织出现问题，例如 CODEOWNERS 文件未按预期工作。 有关如何防止和解决这些问题的详细信息，请参阅 使用 GitHub Enterprise Importer 排查迁移中的问题。

存储库的已迁移数据

直接或在组织迁移过程中迁移存储库时，只会迁移以下数据。

  • Git 源（包括提交历史记录）
  • 拉取请求
  • 问题
  • 里程碑
  • Wiki（不包括附件）
  • GitHub Actions 流程
  • 提交注释
  • 活动的 Webhook（必须在迁移后重新启用，请参阅启用 Webhook）
  • 仓库主题
  • 存储库设置
    • 分支保护（请参阅分支保护，了解更多详细信息）
    • GitHub Pages 设置
    • 自动关联引用
    • 拉取请求设置
      • 自动删除主分支
      • 允许自动合并
      • 允许合并提交（提交消息设置重置为默认消息）
      • 允许 squash 合并（提交消息设置重置为默认消息）
      • 允许变基合并
  • 发布（每个存储库最多 10 GiB）
  • 上述数据的用户历史记录
  • 附件（请参阅“附加文件”）

不迁移的数据

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

  • 审核日志
  • Code scanning 结果
  • Codespaces 秘密
  • 提交状态检查
  • 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 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 GB (公开预览)：此限制仅适用于源代码****。 若要检查存储库存档是否超出限制，请使用 git-sizer 工具并查看输出中的 blob 总大小。 git-sizer 工具还有助于识别与大型文件、blob 大小、提交大小和可能影响迁移的树计数相关的潜在问题。
  • **元数据的 40 GiB 限制（公开预览）：**Importer无法迁移元数据超过 40 GiB 的存储库。 元数据包括问题、拉取请求、发布和附件。 在大多数情况下，大型元数据是由与发布版本相关联的二进制文件引起的。 可以使用 migrate-repo 命令的 --skip-releases 参数从迁移中排除版本，然后在迁移后手动移动这些版本。
  • 400 MB 文件大小限制：使用 GitHub Enterprise Importer 迁移仓库时，Git 仓库中的单个文件大小不能超过 400 MB****。 请考虑使用 Git LFS 来存储大型文件。 有关详细信息，请参阅“管理大型文件”。
  • Git LFS 对象未迁移：Importer 可以迁移使用 Git LFS 的存储库，但不会迁移 LFS 对象本身。 迁移完成后，可以将其作为后续任务推送到迁移目标。 有关详细信息，请参阅“复制一个仓库”。
  • 所需后续任务：在 GitHub 产品之间迁移时，某些设置不会迁移，必须在新存储库中重新配置。 有关每次迁移后需要完成的后续任务的列表，请参阅“在 GitHub 产品之间迁移的概述”。
  • 延迟的代码搜索功能：迁移存储库后，重新编制搜索索引可能需要几个小时，在重新编制索引完成前，代码搜索可能会返回意外的结果。
  • 为组织配置的规则集可能会导致迁移失败：例如，如果配置的规则要求提交作者的电子邮件地址以 @monalisa.cat 结尾，而要迁移的存储库包含不符合此规则的提交，则迁移将失败。 有关规则集的详细信息，请参阅“关于规则集”。
  • 模特内容可能不可搜索：模特是与导入内容（如问题、拉取请求、注释等）关联的占位符用户。 搜索与模特关联的内容（如已分配的问题）时，可能找不到问题。 回收模特后，通过新所有者可找到内容。 有关详细信息，请参阅“回收 GitHub Enterprise Importer 的模型”。

入门

在产品之间 GitHub 迁移之前，你应该计划好如何进行迁移。 迁移数据之前，需要选择开展迁移的人。 必须向该人员授予迁移源和迁移目的地的所需访问权限。 我们还建议先开展测试迁移。

有关完整迁移过程的概述，请参阅“在 GitHub 产品之间迁移的概述”。