代码托管平台与协作规范：GitLab/GitHub/Gitee 怎么选？
说到智能座舱的版本控制，代码托管平台是绕不开的基础设施。你想想看，一个座舱项目动辄几十个模块，屏幕显示、语音交互、车身控制、OTA 升级……代码全堆在本地？那肯定不行。
我个人习惯是，先根据团队规模和合规要求选平台，再定权限模型，最后把 Merge Request 和 Code Review 流程跑通。这三件事做好了，版本控制就稳了一半。
三大平台对比：GitLab、GitHub、Gitee
先看一张对比表，心里有个底：
| 维度 | GitLab | GitHub | Gitee |
|---|---|---|---|
| 部署方式 | 支持私有化部署（CE/EE） | SaaS 为主，Enterprise 可私有化 | SaaS 为主，企业版可私有化 |
| CI/CD 集成 | 内置 GitLab CI，原生强大 | GitHub Actions，生态丰富 | Gitee Go，基础够用 |
| 权限模型 | 5 级权限 + 组继承，非常细 | 4 级权限 + 团队管理 | 4 级权限 + 企业组织 |
| 合规与安全 | 审计日志、合规认证齐全 | Dependabot、Secret 扫描 | 国内合规，等保支持 |
| 国内访问速度 | 自建取决于网络 | 较慢，需代理 | 极快 |
| 典型场景 | 车企内部、军工、合规要求高 | 开源项目、全球化团队 | 国内企业、政府项目 |
我的建议：如果你在主机厂或 Tier 1 工作，GitLab 私有化部署是首选。我在某头部车企做座舱平台时，就用的 GitLab CE，审计日志和权限继承帮了大忙——有一次安全审查，直接导出所有 MR 记录，半小时搞定。
仓库权限管理：别让所有人都能 push master
权限管理这件事，说白了就是「谁可以读，谁可以写，谁可以合并」。很多团队一开始图省事，给所有人 Maintainer 权限，结果某天有人直接 push 到 master，把 CI 跑挂了……嗯，我经历过。
GitLab 的权限模型我比较常用，分 5 个级别：
- Guest：只能看 Issue 和 Wiki，不能看代码
- Reporter：可以看代码、拉分支，不能写
- Developer：可以 push 到功能分支，创建 MR
- Maintainer：可以合并 MR，管理仓库设置
- Owner：最高权限，可以删除仓库
我一般这样分配：
- 开发工程师 → Developer
- 技术主管 / 架构师 → Maintainer
- 项目经理 / QA → Reporter
- 实习生 / 外部协作 → Guest
注意：master/main 分支一定要加保护规则。我曾经见过一个项目，保护分支只勾了「不允许直接 push」，但没勾「不允许强制 push」——结果有人用 git push --force 把历史覆盖了，回滚花了一整天。
Merge Request 流程：从代码到合入的标准化路径
MR 不是走个形式，它是质量门禁。我参与过的座舱项目，MR 流程一般长这样：
- 创建功能分支：从 master 拉出 feat/xxx 或 fix/xxx
- 本地开发 & 自测：跑通单元测试和静态检查
- 推送 & 创建 MR：目标分支选 master，写好描述和关联 Issue
- CI 自动触发：编译、lint、单元测试、集成测试
- Code Review：至少 1 个 Maintainer 审核
- 通过 & 合并：采用 Squash Merge 保持历史干净
下面这张图把流程串起来了：
关键点：MR 的描述一定要写清楚「改了啥、为什么改、怎么测的」。我见过最离谱的 MR 描述就两个字「修复」，reviewer 根本不知道改了啥，来回问了三轮才通过——浪费时间。
Code Review 规范：别让 review 变成走过场
Code Review 不是找茬，是知识传递和质量兜底。我总结了几条硬规矩：
- 每次 MR 不超过 400 行：超过 400 行，reviewer 很难集中注意力，容易漏掉问题
- 至少 1 个 Maintainer 批准：紧急修复可以放宽，但事后要补 review
- CI 必须全绿：编译不过、测试失败、lint 报错，一律不能合并
- 评论要有建设性：别只写「这里不对」，要写「建议改成 XXX，原因是……」
一个小技巧：我习惯在 MR 里贴一个「Checklist」，让 reviewer 逐项确认：代码风格、边界条件、异常处理、日志打印、兼容性。这样 review 效率高很多，也不会漏项。
避坑指南：我曾经踩过的三个坑
讲点实在的，这些坑我都在项目里遇到过：
- 坑一：权限给得太宽——有人误删了 release 分支，还好有备份。后来我强制所有保护分支只允许 Maintainer 操作。
- 坑二：MR 合并策略混乱——有人用 Merge Commit，有人用 Squash，历史乱成一锅粥。后来统一规定：功能分支必须 Squash Merge，release 分支用 Merge Commit 保留合并点。
- 坑三：Code Review 流于形式——团队忙起来，review 就是点个「Approve」完事。后来我加了「Review 时长统计」，低于 2 分钟的自动标记为无效 review，效果立竿见影。
嗯，这些规范看起来琐碎，但真能帮你省下大把 debug 时间。你想想看，一个座舱项目几十号人同时开发，没有这些规矩，代码库迟早变成一团乱麻。