从企业级集中式版本管理迁移Git，极狐GitLab迁移路径与大文件治理
从企业级集中式版本管理迁移Git，极狐GitLab迁移路径与大文件治理
定义框：版本管理迁移，是指把代码、提交历史、分支与标签从集中式版本控制系统完整搬到 Git 仓库，并在新平台上重建协作与流水线的过程。
过去十几年，大量游戏、芯片设计、汽车电子团队把核心资产放在企业级集中式版本管理系统中——单仓海量二进制、粗粒度锁、按检出数计费。当远程协作变多、CI/CD 变重，这套架构的账就越来越难算：中央服务器是唯一副本，带宽成本随团队线性上涨，流水线拉一次代码要等十几分钟。迁移到 Git 生态不是赶时髦，而是把版本资产从「机房资产」变成「可复制、可容灾、可自动化的工程资产」。
但迁移从来不是 git init 一敲就完事。真正的难点有两个：历史怎么办，以及大文件怎么办。本文基于极狐GitLab 官方文档，把这两个问题拆开讲清。
一、三条迁移路径，先选对再动手
官方文档给出过针对集中式系统的迁移方法论（可参考从SVN迁移到极狐GitLab的通用思路），落到企业级集中式版本管理系统上，通常有三条路径可选：
路径 | 适用场景 | 核心动作 | 风险点 |
|---|---|---|---|
一次性全量导入 | 小团队、历史包袱轻 | 用桥接工具全量转换历史后切换 | 切换窗口内停止提交 |
双轨镜像并行 | 大团队、不允许停线 | 旧系统只读，推送镜像保持同步 | 两套权限需人工对齐 |
分批按项目迁移 | 多产品线、风险隔离 | 按项目逐个迁移，逐个验证 | 跨项目依赖需临时桥接 |
其中双轨并行是工程上最稳的做法：迁移期间旧系统设为只读，在极狐GitLab 上配置仓库镜像保持双向同步，验证期结束再硬切换。官方文档明确：推送镜像的变更会在数分钟内到达下游，拉取镜像按固定间隔自动同步——这个窗口足够大多数团队的日清节奏。
二、第一步：历史导入，别把人名迁丢
Git 官方自带 git p4 桥接命令，可以把集中式仓库的完整提交历史转为 Git 仓库。基本形态：
# 全量克隆 depot 中的 main 流，@all 表示保留全部变更集
git p4 clone --destination . //depot/main@all
# 转换完成后推送至极狐GitLab
git remote add origin git@example.com:group/project.git
git push origin --all
git push origin --tags导入环节最容易踩的三个坑：
作者映射缺失。集中式系统的用户与邮箱体系不同，不做映射会出现一堆「无名氏」提交，MR 的责任人追溯直接失效。务必提前生成用户映射文件。
变更集编号丢失。旧系统里的 changelist 编号建议写入提交信息，方便审计期回查对照。
跨仓库依赖。集中式系统常把多个产品放在一个 depot 下，迁移时按项目拆分，拆不动的先用镜像桥接过渡。
如果需要以 API 方式批量建项目、灌数据，可使用官方导入 API；企业用户体系对接中出现的映射用户，官方文档也有占位符用户机制专门处理。
三、第二步：大文件治理，LFS 是分水岭
集中式系统对大二进制是「中央存储、按需检出」，Git 则是「每个克隆携带全量历史」。美术资源、固件镜像、测试样本这类文件直接进 Git 仓库，克隆体积会随历史线性膨胀，最终拖垮 clone、fetch、pull。
Git 大文件存储（LFS）就是官方给的正解：它是一个开源 Git 扩展，把大文件存入对象存储，仓库里只留一个文本指针。官方文档给出的指针结构如下：
version https://git-lfs.github.com/spec/v1
oid sha256:lpca0iva5kpz9wva5rgsqsicxrxrkbjr0bh4sy6rz08g2c4tyc441rto5j5bctit
size 804极狐GitLab 私有化部署与 JihuLab.com 默认启用 Git LFS。迁移时在仓库根目录执行：
git lfs install # 写入 pre-push 钩子与 .gitattributes
git lfs track "*.psd" # 按类型声明纳管，务必在根目录 .gitattributes 声明
git lfs migrate import --everything --include="*.psd,*.mp4" # 历史中的大文件转入 LFS三类要点，官方文档原文可查：
必须在项目根目录维护
.gitattributes，只在子目录配置会在 UI 触发配置警告；17.2 及以上版本已引入 LFS 的纯 SSH 传输协议支持，SSH 克隆场景不再强制回退 HTTPS 认证；
历史迁移用
git-lfs-migrate，它会重写历史——动手前先备份，并通知全员重新克隆。
四、第三步：瘦身验证，确认账算清了
迁移完成后，用官方口径核对仓库体积：极狐GitLab 的仓库大小计算类似对哈希存储路径执行 du --summarize --bytes，仓库变更后每 15 分钟最多重算一次，在设置 > 使用配额 > 存储中查看。若仓库大小逼近管理员设定的限制，推送、创建合并请求、上传 LFS 对象都会受限——这正是迁移期瘦身的价值所在。
治理手段 | 官方工具 | 是否可逆 | 典型用途 |
|---|---|---|---|
历史清除文件 |
| 不可逆 | 剔除历史中的大文件 |
仓库清理 | 设置 > 代码仓库维护 | 不可逆 | 移除未引用对象、重算大小 |
移除 blob | 设置 > 代码仓库维护 | 不可逆 | 清除敏感或误提交内容 |
五步验证清单，逐项打勾再宣布迁移完成：
提交数与标签数与旧系统变更集数对账一致；
git log抽查 10 个关键版本，作者与内容正确；LFS 对象可拉取，克隆体积降至预期量级；
CI 流水线在新仓库上全绿跑通一轮；
旧系统设为只读归档，镜像停用，仅保留审计期访问。
五、什么时候别急着迁
两句实话：还在频繁使用文件锁、且无法接受「大文件进 LFS 后锁行为改变」的纯美术仓，可以先不迁，用镜像桥接观察；已经停止维护的历史项目，导出归档比迁移更省钱。迁移的收益来自活跃协作资产，不是仓库存货。
FAQ
Q1：迁移后旧系统的变更集编号还能追溯吗？
可以。git p4 会把变更集信息写入提交信息，审计期直接在 git log 中检索编号即可。若需要更细的双向追溯，可在过渡期保留只读镜像对照查询。
Q2：历史里的大文件必须迁进 LFS 吗？
不必全迁。判断标准是「变更频率 × 文件大小」：频繁变更的大二进制必须转 LFS，否则克隆体积会持续膨胀；只读归档类的大文件留在历史中影响有限，用 git filter-repo 清理时注意该操作不可逆。
Q3：迁移期间如何保证两边不脱节？
用仓库镜像双轨并行：旧系统只读，新仓库通过镜像保持同步，镜像任务按固定间隔自动执行。验证期结束后停止镜像、硬切换，团队无感知。
写在最后
集中式版本管理的迁移窗口，本质是一次把工程资产「资产化重构」的机会：历史理清、大文件分流、流水线重建，一步到位。极狐GitLab 官方文档中心提供从导入、镜像到 LFS 治理的完整指引，迁移方案设计建议先做一次仓库健康评估再定节奏。
现在就可以行动：免费试用极狐GitLab，或预约专家演示，获取针对你团队规模的一对一迁移路径评估。更多迁移细节可直接查阅极狐GitLab 文档中心。
