用CodeArts Repo搞定团队代码协作，分支与 MR 实战

一个人写代码怎么都行，几个人一起就得出规矩。最忌讳的就是所有人往 main 上直接推，今天你覆盖了我的改动，明天主线编译挂了全组停摆。CodeArts Repo 是华为云上的 Git 代码托管服务，解决的问题就是让团队协作有秩序。这篇文章讲清分支怎么分、MR 怎么提、评审看什么，以及一套能直接落地的协作规范。

一、分支模型：别所有人挤一条线

最常见的是"主干保护 + 特性分支"模式：

核心原则：主线受保护，日常开发在特性分支上跑，做完通过 MR 合回主线。这样主线始终是可发布状态，谁都能随时拉一份干净的代码。

分支策略有两种主流选法：经典的 GitFlow（有 develop/release/hotfix 多分支，适合版本节奏清晰的团队）和主干开发（只有 main + 短命特性分支，合入频繁，适合持续交付）。小团队从主干开发起步更轻，别一上来就套复杂流程把自己绕进去。

二、MR：把"合代码"变成一次评审

MR（Merge Request，也叫 PR）是协作的核心动作。它的价值不止是合并，更是让别人的代码在被合入前被人看见。

一个合格的 MR 描述长这样：

## 改动说明
把下单接口的库存扣减从"先查后减"改成"数据库原子扣减"，修复超卖。

## 为什么改
并发下单时旧逻辑会出现超卖，已复现（见缺陷单 #1234）。

## 验证方式
- 单元用例：InventoryServiceTest 全绿
- 压测：100 并发下单无超卖

## 关联
关联缺陷 #1234

变更范围聚焦，一个 MR 只做一件事，别把重构和修 bug 混一起，否则评审的人看花眼也看不出你到底改了啥。

三、Code Review 到底看什么

评审不是挑刺，是集体兜底。重点看这几类：

1. 正确性：逻辑对不对，边界条件处理没，空值/异常考虑了没；
2. 安全性：有没有 SQL 注入、硬编码密码、越权风险；
3. 可读性：命名清不清楚，函数是不是太长，有没有该抽出来的重复代码；
4. 测试：关键路径有没有补测试，改动会不会打破已有行为。

小建议：评审意见要具体，说"这里建议加个空判断"比"这写得不对"有用得多。配置 CODEOWNERS 还能让特定目录的改动自动指定评审人，避免漏审：

# CODEOWNERS 示例：这些目录的 MR 自动指派评审人
/src/payment/   @alice @bob
/src/order/     @carol

四、冲突怎么解才不慌

特性分支分叉久了，合回主线常常冲突。处理步骤：

git fetch origin
git checkout feature/xxx
git rebase origin/main      # 把主线新提交接到自己前面
# 遇到冲突，逐个文件解决后
git add <冲突文件>
git rebase --continue
git push -f                 # rebase 后需强推自己分支

相比 merge，rebase 能让提交历史是一条干净的线，但只对自己未合入的分支用，别动已发布的历史。合入前也可以把一堆零散提交 squash 成一个，保持主线历史清爽：

git rebase -i origin/main   # 交互式，把多个 pick 改成 squash

五、用流水线给 MR 加门禁

光靠人评审还不够稳，把质量门禁挂到 MR 上更可靠。典型配置是在流水线里加一个检查阶段，MR 通过流水线才能合入：

stages:
  - build
  - check        # 代码检查（CodeArts Check）
  - test
  - deploy
rules:
  mr_merge:
    - when: merge_request
      stages: [build, check, test]   # MR 触发时只跑构建+检查+测试

这样"合入"和"质量达标"被绑死，带病代码进不了主线。

六、一套小团队能直接用的规范

• 主干保护：main 禁止直接 push，必须走 MR + 至少 1 人评审通过；可配置"必须通过流水线（含代码检查）才允许合入"。
• 分支命名：feature/需求名、bugfix/描述，一眼看懂。
• 提交原子化：一次提交只解决一个问题，回滚时好定位。
• MR 关联工作项：需求、缺陷和代码一一对应，审计和复盘都方便。
• 定期清理：合入后的特性分支及时删，仓库不堆垃圾。

小结

CodeArts Repo 这类托管服务本身不难，难的是把协作规矩立起来。抓住三件事就够了：主干受保护、日常在特性分支开发、合入走 MR 并有人评审。再配合聚焦的 MR、具体的评审意见、干净的 rebase/squash 历史，以及流水线门禁，团队合代码就能从"提心吊胆"变成"有章可循"。规矩不是为了束缚，是为了让所有人都敢放心地改代码，也敢放心地合别人的代码。