3、代码仓库管理：Git分支策略、代码审查流程、自动化测试触发机制
3.1 核心原理：分支策略是协作契约，而非流程装饰
在端到端自动化交付体系中，代码仓库管理承担着“源头治理”的角色。很多团队将 Git 分支策略简单理解为“大家约定怎么起名字”，这远远不够。分支策略的本质是并行开发的安全边界与发布节奏的版本锚点。它决定了代码何时、以何种方式进入主干，也决定了自动化测试在哪个节点被触发、以什么环境作为验证基准。
一个可落地的分支策略必须回答三个问题：
- 集成点在哪里？——所有特性最终汇聚到哪个分支，该分支是否始终可部署。
- 隔离粒度多大？——每个需求/缺陷修复是否拥有独立分支，分支生命周期多长。
- 发布如何回溯？——线上版本对应哪个提交，紧急修复如何绕过未完成特性。
下图展示了本课程推荐采用的 GitFlow + 主干协同 混合策略，它兼顾了版本发布的严谨性与持续集成的敏捷性：
该策略的核心在于：develop 分支始终是“可集成的最近状态”，任何特性分支合并前必须通过自动化测试；main 分支始终是“可部署的发布状态”，只有 release 或 hotfix 分支才能合并进入。这样既保证了开发并行度，又维持了主干的可发布性。
3.2 方法流程：从提交到合并的完整链路
3.2.1 分支命名与生命周期
| 分支类型 | 命名规范 | 来源 | 合并目标 | 生命周期 |
|---|---|---|---|---|
| 主干 | main |
— | — | 永久 |
| 集成分支 | develop |
main |
main |
永久 |
| 特性分支 | feature/<jira-id>-<desc> |
develop |
develop |
需求完成即删除 |
| 发布分支 | release/v<major>.<minor> |
develop |
main + develop |
发布后删除 |
| 热修复 | hotfix/v<version>-<desc> |
main |
main + develop |
修复发布后删除 |
3.2.2 代码审查流程（Pull Request 门禁）
代码审查不是“事后检查”，而是合并前的强制质量门禁。本课程推荐的 PR 流程包含以下硬性检查项：
- PR 描述模板：必须关联需求单号、变更类型（feature/bugfix/refactor）、影响范围、测试说明。
- 至少 1 名 Reviewer 批准：核心模块（支付、权限、数据迁移）要求 2 名 Reviewer。
- CI 检查全部通过：包括编译、单元测试、代码风格检查（ESLint/Checkstyle）、安全扫描。
- 无未解决的对话：所有评论必须 resolve 或明确关闭。
一个典型的 PR 合并命令如下：
# 创建特性分支（基于最新的 develop）
git checkout develop && git pull
git checkout -b feature/PAY-1023-refund-timeout
# 开发完成后提交并推送
git add .
git commit -m "feat(payment): add refund timeout retry logic"
git push origin feature/PAY-1023-refund-timeout
# 在 GitHub/GitLab 创建 PR，目标分支选择 develop
# 等待 CI 通过 + Reviewer 批准后，使用 Squash 合并
git checkout develop && git pull
git merge --squash feature/PAY-1023-refund-timeout
git branch -D feature/PAY-1023-refund-timeout3.2.3 自动化测试触发机制
测试触发不是“定时跑一下”，而是与 Git 事件深度绑定的分层策略。本课程采用以下触发矩阵：
- Push 到 feature 分支：仅触发快速检查（编译 + 该模块的单元测试），耗时控制在 5 分钟内。
- PR 创建/更新：触发完整单元测试 + 静态代码分析 + 测试覆盖率报告。
- 合并到 develop：触发集成测试 + 构建 Docker 镜像 + 自动部署到 dev 环境。
- 创建 release 分支：触发全量回归测试（含端到端测试）+ 性能基准测试。
- 打 tag（v*）：触发生产发布流水线，包含安全扫描和灰度部署。
3.3 案例：一次带缺陷的合并如何被拦截
某团队在开发“订单导出”功能时，开发者小张在本地运行测试全部通过，但推送到 feature/order-export 分支并创建 PR 后，CI 流水线在 静态分析阶段发现了一个空指针隐患（NPE），同时单元测试中与“金额格式化”相关的 3 个用例失败。原因是小张本地 JDK 版本与 CI 环境不一致，且未运行完整的测试套件。
由于 PR 门禁配置了“测试未通过禁止合并”，该 PR 被自动锁定。Reviewer 在评论中指出问题后，小张修复代码并重新推送，CI 重新触发，全部通过后 Reviewer 批准合并。整个过程约 40 分钟，避免了缺陷流入 develop 分支。
git hook（如 pre-push）运行增量测试，可大幅减少 CI 的无效触发。例如使用 husky + lint-staged 只检查暂存区的文件。
3.4 误区与复盘：分支策略常见陷阱
复盘案例：某团队曾允许“紧急修复”直接 push 到 main，结果一次数据库连接池参数调整未经过测试，导致线上服务在高峰期出现连接耗尽。事后分析发现，该修复本应走 hotfix 分支，至少应触发集成测试。团队随后在 GitLab 中配置了 “main 分支禁止直接 push” 的保护规则，并要求所有 hotfix 必须关联缺陷单。
另一个常见问题是测试触发粒度与分支策略不匹配。例如，所有分支都跑全量端到端测试，导致 CI 队列积压，开发者等待时间过长，反而开始绕过测试。正确的做法是：按分支类型配置不同的测试深度，让“快速反馈”与“全面验证”各司其职。
最后，请记住：分支策略和测试触发机制不是静态配置，而是需要持续演进的协作契约。每季度回顾一次分支模型是否适应当前团队规模和发布频率，根据实际数据（如合并等待时间、CI 失败率、缺陷逃逸率）进行调整，才能让代码仓库真正成为交付流水线的稳固起点。