当前位置：首页 > 文章列表 > 科技周边 > 业界新闻 > GitHub 企业实时迁移正式可用后哪些数据可以迁移

GitHub 企业实时迁移正式可用后哪些数据可以迁移

来源：17golang原创 2026-09-06 02:44:34 0浏览收藏

GitHub Enterprise Live Migrations（ELM）正式可用后，企业迁移的关键变化不是“所有 GitHub 数据都能自动搬家”，而是可以把单个仓库的大部分仓库级数据在持续同步下迁到 GitHub Enterprise Cloud with Data Residency（GHE.com）。组织设置、团队、项目和组织级 Webhook 不在迁移范围内；规则集不迁移，分支保护也只是部分迁移。

要点速览

ELM 适合重要仓库、大型 monorepo 和不能长时间停机的业务仓库；普通仓库仍可考虑 GitHub Enterprise Importer（GEI）。
Git 历史、LFS、Wiki、Issues、Pull requests、Releases、仓库级 Actions 设置等可以随仓库迁移。
切换前必须单独安排组织资源、规则集、分支保护允许列表和未支持实时事件的人工复核。

先判断仓库是否适合 Enterprise Live Migrations

ELM 的价值在于降低开发者等待时间：初始回填后，源仓库仍可继续工作，Webhook 会把部分后续变化交给迁移服务；到 cutover 时，源仓库才会短暂变为只读。GitHub 官方把它定位为 GEI 的补充，而不是所有仓库的默认替代品。

可以先按下面四个问题筛选：

判断项	更适合 ELM 的情况	需要注意
停机容忍度	发布和协作不能停数小时	cutover 仍需要排空最后的变更
仓库形态	大型、历史深的 monorepo	先确认 release asset 单个不超过 2GB
源端版本	GHES 3.17 及以上对应支持补丁版本	HTTP 地址、出站网络和 Management Console 设置也要满足条件
迁移数量	按业务优先级分批迁移	单个 GHES 最多并发 10 个，目标企业最多 20 个

如果仓库可以接受短暂停机、规模也不大，GEI 可能更简单。ELM 更适合把“停机风险”当作主要约束的仓库，而不是单纯追求功能数量。

仓库级数据能带走什么

ELM 一次迁移一个仓库，覆盖范围集中在仓库本身。代码侧包括 refs、对象和完整提交历史；启用条件满足时，LFS 对象和 Wiki Git 仓库也会迁移。协作侧包括 Issues、评论、反应、标签关联、时间线事件，以及 Pull requests、评审、行内评论和评审线程。

GitHub Enterprise Live Migrations 中仓库级数据与组织级人工配置的边界关系图 — 图1：把 ELM 的迁移边界分成仓库级资源和组织级资源，避免把企业配置误当成仓库数据。

仓库设置和发布资产也不能漏盘：仓库描述、可见性、默认分支、启用功能、仓库 Webhook、Topics、Pull request 设置、仓库级 Actions 配置、Autolinks、Pages、Labels、Milestones、Releases、Commit comments、Status checks、Check runs 和 Check suites 都在官方迁移数据清单中。Release asset 的单个文件上限是 2GB，LFS 则要求源端已启用 LFS。

最容易误判的缺口在哪里

第一类缺口是“仓库数据”和“组织数据”的边界。组织设置、Teams、Projects、组织级 Webhooks 不会随仓库迁移；ELM 至多在目标端创建目标组织账号，组织结构和权限仍要人工配置。

第二类缺口是保护规则。Repository rulesets 不迁移；分支保护只保留部分开关状态，不保留允许的用户、团队或应用，也不会带走绕过者、强推者、状态检查应用绑定、合并队列和部署要求等配置。迁移后必须在允许开发者工作前重新检查。

第三类缺口是实时更新。Pull request 的创建、编辑、关闭等事件有支持范围，但例如 review requested、synchronize、locked 等事件不在实时更新列表中；Check runs、Check suites 和 Pages 配置只在初始回填阶段导出，不会继续由 Webhook 更新。