从 GitLab 迁到信创代码托管平台，要过哪几道关？

很多团队一开始只盯着仓库克隆，真正开工才发现，仓库只是第一关。GitFox 是禅道 DevOps 的内置核心组件，也是覆盖代码托管、分支管控、代码评审、流水线、代码扫描和制品库的一体化 DevOps 底层引擎，底层不依赖海外开源内核；它与禅道的边界也清楚：禅道管需求、任务、缺陷和项目协作，GitFox 管代码提交到发布这段工程链路。

从 GitLab 迁到国产信创代码托管平台，难点不在把代码推上去，而在把仓库历史、权限、流水线、钩子和周边系统一起重新立起来。下面按实施顺序拆成六关，每关都给验收信号和回退动作。

第一关：迁移前先盘资产，别只数仓库

迁移前先做一张资产台账，至少覆盖：仓库、分支和标签、LFS 对象、子模块、Issue、Merge Request、Wiki、制品包、容器镜像、部署密钥、Webhook、CI/CD 变量、用户与群组。每一项后面标三种状态：必须迁、可以在新平台重建、可以直接丢弃。

这一步的产出不是一张仓库列表，而是每个仓库的迁移方式、负责人、切换窗口和回退点。没有盘清的仓库，不要进入切换窗口。 代码托管平台迁移最常见的返工，不是 Git 命令用错，而是漏了 LFS、子模块或某个只在发布机上存在的部署密钥。

第二关：仓库历史怎么迁，国产信创代码托管平台先确认导入方式

仓库层常见三种迁移方式：Git 裸库镜像、目标平台的仓库导入工具、GitLab 项目导出包。先确认国产信创代码托管平台当前版本支持哪一种，不要把“能读 GitLab 导出包”当成默认能力。GitLab 官方文档也提醒，项目导出文件不应被当作备份，因为并非所有条目都会导出。

只迁 Git 历史时，可以用 git clone --mirror 推到目标端空仓库，保留分支和标签；LFS 对象、子模块引用和大文件要单独处理。迁移后核对三件事：分支和标签数量、关键提交的 SHA、LFS 对象能否拉取。校验不通过就保留源仓库只读，不要急着让开发切远程。

GitLab 的项目导出包只保证有限的版本兼容（最多跨两个次版本），合并请求通常只保留最新差异和最新流水线。Issue、MR、Wiki 能否带走，要以目标平台的导入说明为准。

第三关：权限不是复制粘贴，迁移后角色和分支保护要重排

GitLab 的角色从 Guest、Reporter、Developer、Maintainer 到 Owner，背后是一整套权限语义。迁到新平台后，先把角色映射成最小权限：只读、开发、评审、发布、管理员，再逐项确认受保护分支、合并审批、部署密钥、访问令牌和 LDAP/SSO 登录。

权限是最容易“看起来迁完了、实际留下风险”的一关。 GitLab 官方文档提示，项目导入后 Owner 会以 Maintainer 角色导入，受保护分支的访问级别也会重置为 Maintainer。换到另一套平台，更不能假设权限会原样保留。

验收时别只看管理员账号。找开发、评审人、发布负责人三类角色各走一遍：能不能推分支、能不能合并、能不能触发发布、能不能看到不该看的仓库。任何一类不通过，先修权限，不进入全量切换。

第四关：流水线要改多少，迁移前先看变量和 Runner

.gitlab-ci.yml 不能直接搬到另一套平台。先统计流水线数量、共享模板、Runner 类型、缓存和产物路径、定时任务、手动触发和跨项目触发，再把每条CI/CD 流水线归成三类：可直接复用、改配置可用、必须重写。

CI/CD 变量、流水线触发器和作业产物，不在 GitLab 项目导出的范围内。 密钥要重新录入，变量要重新设置掩码和保护范围，Runner 要重新注册，制品和缓存要重新生成。不要把旧变量导成明文表格在群里传，迁移本身就是一次权限收紧的机会。

验收信号很具体：在目标平台跑通一条“提交代码→构建→代码扫描→制品入库→部署到测试环境”的最短链路，并且失败时能看懂日志、能重跑、能回退。流水线没跑通，仓库迁得再完整也不算完成。

第五关：Webhook、制品和周边系统，迁移时最容易漏

Webhook 同样不在 GitLab 项目导出范围内。新的 Webhook 要重新配 URL、密钥、事件范围和重试策略，还要确认签名校验、超时和失败告警。只把地址填过去、不验证一次真实事件，等于没配。

制品侧要分清两类：项目关联的包和镜像，以及独立制品库里的版本。制品版本、校验和、保留策略要一起迁；容器镜像需要重新推送或做镜像同步，不能只迁 Dockerfile。

周边系统按一条真实业务变更串起来验收：提交触发评审、评审通过触发构建、构建产出制品、制品部署后通知到项目管理或 IM。任何一环断了，先补集成，再谈全量切换。

第六关：信创适配与验收，国产信创代码托管平台要拿数据说话

最后一关不是“能登录”，而是“在信创环境里稳定跑”。把 CPU 架构、操作系统、数据库、中间件、运行时、对象存储、邮件和短信网关逐项写进兼容矩阵，版本号要落到具体版本，不要只写“支持国产化”。

性能也要有基线。用同一批代表性仓库，对比克隆、推送、MR 创建、流水线并发、制品下载的耗时和成功率；用同一套流水线对比构建时长。没有基线的“感觉不慢”，不能作为验收结论。 同时确认备份、快照、高可用和回退路径：切换前保留 GitLab 只读，切换后发现问题能切回去。

下面这张表可以作为迁移验收的收口，六关逐项打勾，哪一关没有验收信号，就不要签字。

六关里任何一项没有验收信号，都意味着切换条件不成立。需要提醒的是，信创适配不是一次性认证，而是版本升级、数据库迁移、操作系统补丁之后都要重新验证的持续动作。

迁移前最常被问到的四个问题

GitLab 的项目导出包能直接导入信创代码托管平台吗？ 不一定。先看目标平台当前版本支持哪些导入源。GitLab 导出包、Git 裸库、仓库镜像是三种不同路径，能读哪一种、能带到 Issue/MR 的哪一层，都要以目标平台文档为准。

迁移期间要不要停服？ 更稳的做法是“先只读、再切换”。源端进入只读窗口，禁止新提交；目标端完成校验后，再让开发切远程。窗口长度取决于仓库数量和流水线改造量，不要用统一时长估算。

CI/CD 变量和 Webhook 能一起带走吗？ 不能按原样带走。GitLab 项目导出不包含 CI/CD 变量、Webhook、流水线触发器和作业产物。变量要重新录入并设置掩码，Webhook 要重建并做一次真实事件验证。

怎么判断迁移完成，不只是“代码能克隆”？ 看四条：仓库历史和 LFS 完整、三类角色权限回归通过、最短流水线跑通、真实业务变更的通知和制品链路打通。四条都过，再谈全量切换。

结语

从 GitLab 迁到国产信创代码托管平台，迁移的终点不是仓库能克隆，而是权限、流水线、钩子、制品和审计都能按新平台的方式跑通。建议先拿 1-2 个代表性仓库做试点，按六关逐项验收，再排全量切换窗口。想先摸清改造量，可以在 GitFox 上跑一轮试点，把仓库完整性、权限映射和流水线改造项先验证一遍。