代码评审平台迁移极狐GitLab，评审规则与工作流重建指南
代码评审平台迁移极狐GitLab，评审规则与工作流重建指南
用了七八年评审型Git服务器的团队，迁移时最怕的不是搬代码——代码搬家一条命令的事。真正难的是：那些沉淀了多年的评审规则、门禁和团队习惯，换个平台就散了。有人在迁移后评审流于形式，有人干脆退回线下口头评审，合并请求堆了三天没人看。
这篇文章把这件事拆开讲清楚：代码怎么迁、评审规则怎么等价重建、团队习惯怎么平稳过渡。
定义框：评审型代码托管平台是以「推送触发评审、评分达标才能合入」为核心工作流的代码托管与代码评审一体化工具，常与大中型企业集中式权限体系配合使用。
一、先看清旧工作流里到底有什么
迁移前先盘点，把旧平台上的机制逐项列出来，而不是只搬仓库。典型的评审型平台工作流包含这些要素：
旧平台机制 | 作用 | 极狐GitLab 对应能力 |
|---|---|---|
推送到特殊评审引用触发评审 | 代码不直接进分支，先进评审队列 | 合并请求（Merge Request） |
评审评分/门禁阈值 | 达到分数才能提交合入 | 审批规则 + 所需批准数量 |
OWNER 文件指定文件责任人 | 按路径找人评审 | CODEOWNERS 文件 |
分支写入白名单 | 限制谁能改关键分支 | 受保护分支 + 允许推送和合并 |
提交信息校验钩子 | 强制规范提交格式 | 推送规则（专业版） |
盘点的产出是一张「规则对照清单」，迁移时逐项勾销。经验上，80% 的规则能直接映射到极狐GitLab 的开箱能力，剩下 20%（如自定义评分插件）需要用审批规则加流水线的组合替代。
二、代码库导入：两条官方路径
极狐GitLab 支持把既有 Git 代码仓库完整迁移过来，历史、分支、标签全部保留。常用两种方式：
方式一：拉取镜像（适合批量、持续同步过渡期）。 在项目中配置拉取镜像后，极狐GitLab 会从上游仓库按计划检索变更。根据官方文档，上游变更会在上次拉取 30 分钟后自动拉取，且此行为无法禁用；连续失败 14 次后镜像会被标记为硬失败并停止更新（参考从远程代码仓库拉取）。这种方式适合迁移过渡期——旧平台还在跑，新平台持续追平。
方式二：裸仓库直接推送（适合一次性切换）。 用 git clone --mirror 拿到完整裸仓库，再整体推过来：
git clone --mirror https://old-review.example.com/team/app.git
cd app.git
git push --mirror https://gitlab.example.com/team/app.git推完后核对分支数、标签数和 HEAD 提交哈希，确认无损。批量迁移几十上百个仓库时，把这两条命令写进脚本循环执行，再用 API 抽查每个仓库的分支数量即可。
三、评审规则重建：三个支柱
支柱 1：CODEOWNERS 接管「按路径找人」
在仓库中放一个 CODEOWNERS 文件，为不同路径指定责任人。极狐GitLab 按固定顺序检查三个位置：根目录 ./CODEOWNERS、./docs/CODEOWNERS、./.gitlab/CODEOWNERS，找到第一个即生效（参考代码所有者）：
# 默认所有者：未匹配任何规则的文件由核心团队审批
* @team-core
# 前端资源由前端组审批
*.css @team-frontend
# 配置目录变更必须过 SRE
/config/ @team-sre支柱 2：审批设置收紧「谁有资格批准」
在设置 > 合并请求 > 审批中，官方提供了四个关键开关：防止合并请求创建者批准（默认开启）、阻止添加提交的用户批准、禁止在合并请求中编辑审批规则、代码所有者的文件变更后移除其审批（参考合并请求审批设置）。这四项全开，等价于旧平台「评审者不能是提交者本人」的硬约束。
支柱 3：受保护分支强制执行
规则写完不算完，还得让它在合并前生效。官方对生产分支的推荐策略是：允许合并设为仅维护者，允许推送和合并设为无人，并打开需要代码所有者审批开关。启用后，所有合并请求在合并前必须获得匹配路径的代码所有者批准，直接推送涉及代码所有者文件的变更会被拒绝（参考受保护分支）。
再叠加一条流水线门禁，替代旧的自动检查项：
merge_gate:
stage: test
script:
- make lint
- make unit-test
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"四、团队习惯过渡：五步灰度
规则重建只完成一半，另一半是人。评审型平台的用户习惯了「推一下就进评审」，换成合并请求模型后需要缓冲期：
双轨期（1-2 周）：新旧平台并行，新项目只走合并请求，存量项目继续旧流程；
模板先行：配好合并请求描述模板和评审检查单，降低切换成本；
试点团队：选一个配合度高的团队先切，把问题在最小范围内暴露完；
全员培训：用一次内部演示讲透「分支-合并请求-审批-合并」四步，重点讲清与自己旧习惯的差异；
停旧限新：旧平台转为只读，所有新变更强制走极狐GitLab，过渡完成。
五、常见问题
FAQ 1：迁移后旧评审记录（评分、评论）会丢吗？
会。Git 代码仓库的提交历史、分支、标签可完整迁移，但评审评论和评分属于平台数据，不在 Git 协议范围内。建议迁移前把仍在途的评审项在旧平台收尾归档，避免追溯断档。
FAQ 2：CODEOWNERS 和审批规则有什么区别，该用哪个？
两者配合使用：CODEOWNERS 把审批绑定到具体文件路径（如 .css 归前端组），审批规则定义与路径无关的通用评审范围（如安全团队评审所有变更）。路径相关的用 CODEOWNERS，全局门禁用审批规则。
FAQ 3：迁移期间仓库两边都在提交，怎么保证一致？
过渡期用拉取镜像保持追平：极狐GitLab 会自动从上游拉取变更。但要注意官方约束——镜像分支一旦与上游分歧，极狐GitLab 默认停止更新该分支以防止数据丢失。所以过渡期内应以旧平台为唯一写入源，切换完成后立即冻结旧平台。
如果贵团队正卡在评审平台选型或迁移评估上，可以预约极狐GitLab 产品演示，或先申请免费试用，在一个真实仓库上把上述规则跑通再决定。更多配置细节见极狐GitLab 文档中心。
