4. 版本仓库与分支策略：Git 在策略版本管理中的应用

在风控策略的持续迭代中，策略代码、规则配置、模型文件与决策流定义都需要像软件代码一样进行版本控制。Git 作为分布式版本控制系统，为策略版本管理提供了分支隔离、历史追溯与协同开发的能力。本章将重点介绍如何基于 Git 设计主分支、开发分支与热修复分支，以支撑风控策略的稳定发布与快速响应。

4.1 策略版本仓库的结构设计

风控策略仓库通常按业务线或产品线组织，每个仓库包含以下核心目录：

• rules/：规则配置文件（如决策表、评分卡、规则脚本）
• models/：模型文件（如 PMML、ONNX 或 pickle 格式）
• pipelines/：决策流定义（如 DAG 配置、节点拓扑）
• config/：全局参数与阈值配置
• tests/：策略单元测试与回测脚本

4.2 分支策略设计：三线模型

参考 Git Flow 与 Trunk-Based 的折中方案，风控策略版本管理推荐采用 主分支（main）、开发分支（develop） 与 热修复分支（hotfix） 的三线模型。该模型在保证发布稳定性的同时，支持并行开发与紧急修复。

4.3 分支协作流程

下图展示了风控策略版本管理中分支的创建、合并与发布流程：

4.4 主分支（main）的守护策略

主分支是线上风控策略的精确镜像，任何对 main 的提交都必须经过严格的准入控制：

• 代码审查（Code Review）：所有合并请求必须至少由两名资深风控工程师审核。
• 自动化测试门禁：合并前必须通过策略回测、规则覆盖率检查与性能基准测试。
• 版本标签：每次合并到 main 后，自动打上语义化版本标签（如 v1.2.0）。
• 不可变历史：禁止对 main 分支进行强制推送（force push）或历史重写。

4.5 开发分支（develop）的集成节奏

开发分支是日常策略迭代的集散地。风控团队通常按 双周迭代 的节奏管理 develop 分支：

1. 第一周：各成员从 develop 拉取 feature 分支，进行新规则开发或模型替换。
2. 第二周前半：feature 分支合并回 develop，触发集成测试与冲突解决。
3. 第二周后半：从 develop 拉取 release 分支，进行预发布验证与回归测试。
4. 发布日：release 分支合并到 main，打标签并部署上线。

4.6 热修复分支（hotfix）的紧急响应

当线上策略出现紧急问题（如误杀率飙升、规则执行异常、模型加载失败）时，热修复分支提供快速修复通道：

4.7 分支策略的自动化支撑

为了保障分支策略的执行效率，建议在 CI/CD 流水线中集成以下自动化检查：

• 分支命名校验：拒绝不符合 feature/、hotfix/、release/ 命名规范的分支推送。
• 合并冲突检测：在创建合并请求时自动检测冲突，并阻塞存在冲突的合并。
• 策略一致性校验：确保规则文件、模型文件与决策流定义之间的引用关系完整。
• 版本号自增：根据合并目标分支自动建议下一个版本号，避免人工误操作。

下图展示了分支策略与自动化流水线的集成关系：

4.8 分支策略的常见避坑指南