4、代码仓库管理：分支保护策略、Code Review流程、标签与Release管理
说到代码仓库管理，我见过太多团队在这上面栽跟头了。有的团队分支乱得像蜘蛛网，有的团队合并代码全靠「谁手快谁说了算」。嗯，今天我们就来聊聊怎么把这块管好。
4.1 分支保护策略：别让任何人能直接往主干上推代码
我个人习惯，主干分支（main/master）必须锁死。什么意思？就是不允许任何人直接 push，也不允许直接 merge。所有变更必须走 Pull Request。
为什么会这样？
我在项目中遇到过，有个同事急着下班，直接把未测试的代码 push 到了 master。结果第二天整个 CI 流水线全红，大家排查了半天才发现问题。从那以后，我就坚持：主干分支必须受保护。
分支保护的核心规则：
- 禁止直接 push 到主干分支
- 必须通过 PR 才能合并
- 合并前必须通过 CI 检查
- 必须有至少 1 人 Code Review 通过
在 GitLab 或 GitHub 上配置分支保护其实很简单。以 GitLab 为例：
# 在项目设置中开启分支保护
Settings → Repository → Protected Branches
# 选择主干分支，设置：
- Allowed to merge: Maintainers + Developers
- Allowed to push: No one
- Code owner approval: Required你想想看，如果每个人都能往主干上推代码，那还要 CI 干什么？说白了，分支保护就是给代码质量上了一道保险。
4.2 Code Review 流程：不是走过场，是真看代码
Code Review 这件事，很多团队做成了形式主义。有人点个「LGTM」就算完事，有人根本连代码都不看。我曾经在一个项目里，就因为 Review 没仔细看，把一个空指针异常的 bug 放到了生产环境。
所以我的建议是：Code Review 要有流程，更要有标准。
我推荐的 Code Review 流程：
- 开发者创建 PR，写好描述和变更说明
- CI 自动运行单元测试和静态检查
- 至少 2 名 Reviewer 进行审查
- Reviewer 提出修改意见，开发者修复
- 所有讨论 resolved 后，由 Maintainer 合并
这里有个小技巧：PR 不要太大。我一般建议一个 PR 不超过 400 行代码变更。为什么呢？因为超过这个量，Reviewer 就很难仔细看了。你想想看，让你一次性 review 2000 行代码，你也会头疼吧？
Review 的时候重点看什么？
- 逻辑是否正确（这是最基本的）
- 有没有边界情况没处理
- 代码风格是否一致
- 有没有引入新的依赖
- 测试用例是否覆盖了变更
注意：Code Review 不是找茬，是帮团队把关。我曾经见过有人把 Review 当成权力斗争的工具，这完全走偏了。Review 的目的是提升代码质量，不是证明谁比谁厉害。
4.3 标签与 Release 管理：给版本打上标记
标签（Tag）这个东西，说白了就是给某个 commit 打个标记，方便以后回溯。Release 则是把标签和发布说明打包在一起。
我个人习惯，每次发布正式版本都要打标签。标签的命名规则要统一，比如：
# 语义化版本号
v1.0.0
v1.1.0
v2.0.0-rc.1
# 或者带日期的版本号
v2024.01.15
v2024.03.20我建议使用语义化版本号（SemVer），格式是：主版本号.次版本号.修订号。
| 版本类型 | 示例 | 说明 |
|---|---|---|
| 主版本 | v2.0.0 | 不兼容的 API 变更 |
| 次版本 | v1.1.0 | 向下兼容的新功能 |
| 修订号 | v1.0.1 | 向下兼容的问题修复 |
| 预发布 | v1.0.0-rc.1 | 候选版本，用于测试 |
创建 Release 的时候，我习惯把变更记录写清楚。比如：
## v1.2.0 (2024-03-15)
### 新增
- 支持 I2C 总线驱动
- 添加看门狗定时器功能
### 修复
- 修复 SPI 通信超时问题
- 修复内存泄漏（感谢 @zhangsan 报告）
### 变更
- 升级 FreeRTOS 到 v10.5.0
- 优化任务调度策略嗯，这里要注意：Release 说明不是写给机器看的，是给人看的。所以要用自然语言描述清楚变更内容，让团队成员和用户都能看懂。
标签和 Release 的最佳实践：
- 每次正式发布都要打标签
- 标签名和 Release 版本号保持一致
- Release 说明要包含变更记录
- 预发布版本用 rc、alpha、beta 标识
- 历史标签不要删除或修改
我曾经在一个项目里，因为没打标签，导致回滚的时候找不到对应的 commit。最后只能靠 git log 一个一个翻，那叫一个痛苦。所以我现在养成了习惯：发布必打标签，回滚有据可查。
好了，关于代码仓库管理这块，核心就是三点：分支保护防乱改、Code Review 保质量、标签 Release 管版本。这三件事做好了，团队的协作效率能提升一大截。