代码仓库迁移指南：从国内/海外托管平台迁至极狐GitLab
代码仓库迁移指南：从国内/海外托管平台迁至极狐GitLab
代码仓库迁移是企业换用平台时最敏感、最容易翻车的环节：仓库、Issue、Merge Request、流水线配置，任何一环丢数据都会造成信任危机。本文基于极狐GitLab官方导入能力，给出从国内或海外托管平台迁至极狐GitLab的完整操作路径与注意事项。
一、迁移前：盘点与规划
在动手导入之前，先完成三件事：
盘点资产清单：仓库列表、分支与标签、Issue/MR 数量、Webhook、CI/CD 变量、仓库镜像配置。
确认权限映射：平台间的角色体系不同，迁移后需要重新配置成员角色（开发者/维护者/所有者）。
确定迁移窗口：选择低流量时段执行，避免迁移过程中产生大量增量数据。
二、官方导入方式：导入项目功能
极狐GitLab官方提供项目导入（Import projects）能力，支持从多种来源将现有仓库导入。入口位于：新建项目 → 导入项目。导入时不仅迁移 Git 仓库本身，还会同步关联数据（Issue、MR、里程碑、看板、标签等，具体范围以官方文档为准）。
以从国内某Tee平台迁入为例：
# 1. 在源平台生成迁移包/导出文件（或直接使用官方导入器按链接导入）
# 2. 在极狐GitLab中：新建项目 -> 导入项目 -> 选择对应导入方式
# 3. 填写源仓库地址与访问凭证，开始导入
# 4. 导入完成后核对：分支、标签、MR、Issue 数量与源端一致从海外某Hub平台迁入： 官方支持直接通过仓库 URL 导入，同样可保留仓库的提交历史与分支结构。
三、迁移中的关键步骤
1. 仓库导入后的验证清单
git log提交历史完整、无丢失；所有分支与标签已同步；
Issue 与 MR 的编号、评论、附件可访问；
受保护分支、Code Owners、审批规则按新平台的配置方式重新建立。
2. 流水线配置迁移
源平台的 CI 配置无法直接复用为 .gitlab-ci.yml，需要按极狐GitLab的流水线语法重写。官方提供两条路径降低工作量：
手动迁移：参考官方文档的 YAML 语法（stages、jobs、rules、needs、include）重写；
AI 辅助迁移：极狐GitLab Duo 提供 Convert to GitLab CI Flow，可自动将现有流水线配置迁移为极狐GitLab CI/CD 配置，减少人工投入。
3. 过渡期双轨运行
迁移完成后不急于关停源平台，利用仓库镜像（Repository Mirroring）保持双向/单向同步运行一段时间，验证稳定后再正式切换 DNS 与文档入口。
四、迁移后的长期动作
成员与权限重建：按新平台的群组结构重新组织项目归属；
CI/CD 变量迁移：将密钥类变量存入极狐GitLab的 CI/CD 变量（推荐使用受保护变量与掩码变量）；
安全能力启用：旗舰版开启密钥检测、SAST、SCA 等扫描，对存量代码做一次全量体检；
通知与 Webhook 迁移：更新 CI/CD 通知与外部系统集成。
五、常见坑与规避
大仓库导入超时：超大仓库建议先
git gc瘦身，或采用镜像+增量策略；LFS 数据：确认 Git LFS 文件是否正确迁移，否则历史大文件可能无法检出；
权限遗漏：迁移后第一时间核对敏感仓库的访问权限，避免默认开放。
六、总结
迁移不是"复制仓库"，而是"重建治理"：仓库历史、Issue/MR、流水线与权限体系都要在新平台重新就位。极狐GitLab官方提供项目导入、仓库镜像与 AI 流水线迁移（Convert to GitLab CI Flow）三层能力，覆盖"迁入、过渡、重写"全流程。按本文清单执行，可以显著降低迁移风险。
迁移功能的详细说明与支持范围，参见极狐GitLab官方文档中心 docs.gitlab.cn「导入项目」章节。
