策略版本管理基础概念：版本号规范、分支策略与发布管理
在量化策略的迭代过程中，版本管理是保障策略可追溯、可回滚、可协作的基石。本节将围绕三个核心维度展开：语义化版本号规范、主流分支策略以及标签与发布管理，帮助团队建立标准化的版本控制体系。
1. 语义化版本号规范
语义化版本（Semantic Versioning，SemVer）是目前业界最广泛采用的版本号格式。它通过三段式数字 MAJOR.MINOR.PATCH 清晰表达版本变更的兼容性影响。
| 版本段 | 名称 | 变更条件 | 量化策略示例 |
|---|---|---|---|
| MAJOR | 主版本号 | 不兼容的 API 或策略逻辑重大重构 | 因子体系重构、信号生成逻辑重写 |
| MINOR | 次版本号 | 向下兼容的功能新增或参数扩展 | 新增风控规则、增加交易品种支持 |
| PATCH | 修订号 | 向下兼容的问题修复或性能优化 | 数据源 bug 修复、计算精度优化 |
预发布与构建元数据： 在正式版本号后可附加
-alpha.1、-beta.2 或 +build.20250321 等标签，用于区分内部测试版本与正式发布版本。例如 2.1.0-beta.1 表示主版本 2、次版本 1 的第一个 Beta 测试版。
# 语义化版本号示例
1.0.0 # 初始稳定版本
1.1.0 # 新增了滑点优化模块
1.1.1 # 修复了滑点计算中的除零错误
2.0.0-alpha.1 # 因子体系重构后的第一个内测版
2.0.0 # 因子体系重构正式发布2. 分支策略：Git Flow 与 Trunk Based
分支策略决定了团队如何并行开发、集成与发布。量化策略团队通常面临高频调参、因子实验与稳定发布并存的场景，选择合适的分支模型至关重要。
核心对比： Git Flow 适合有明确发布周期、需要多版本并行维护的团队；Trunk Based 适合追求持续集成、快速迭代的团队。
| 维度 | Git Flow | Trunk Based |
|---|---|---|
| 长期分支数 | 2 个（master + develop） | 1 个（main/trunk） |
| 功能开发方式 | 从 develop 拉取 feature 分支 | 短生命周期 feature 分支（< 1天） |
| 发布流程 | 从 develop 拉取 release 分支，测试后合并到 master | 从 trunk 直接打标签发布 |
| 热修复 | 从 master 拉取 hotfix 分支，修复后合并到 master 和 develop | 在 trunk 上修复并快速验证 |
| 适用场景 | 多版本并行、严格发布审批 | CI/CD 成熟、单版本持续交付 |
3. 标签与发布管理
标签（Tag）是 Git 中为特定提交打上的不可变标记，通常与语义化版本号一一对应。发布管理则围绕标签建立从构建、验证到部署的标准化流程。
3.1 标签命名规范
- 正式版本：
v{MAJOR}.{MINOR}.{PATCH}，例如v1.2.3 - 预发布版本：
v{MAJOR}.{MINOR}.{PATCH}-{prerelease}，例如v2.0.0-rc.1 - 附带构建信息：
v{MAJOR}.{MINOR}.{PATCH}+{build}，例如v1.0.0+build.20250321
避坑提示： 标签一旦推送至远程仓库，应视为不可变。禁止对已发布的标签进行 force push 或删除后重新打标，否则会导致下游依赖版本校验失败。
3.2 发布管理流程
- 代码冻结： 从 develop 或 trunk 拉取 release 分支，仅允许 bug 修复，禁止新增功能。
- 版本号更新： 在 release 分支中更新策略配置文件中的版本号字段。
- 回归测试： 执行全量回测、压力测试与 PSI 漂移检测。
- 打标签： 测试通过后，在 release 分支上创建语义化版本标签。
- 合并与发布： 将 release 分支合并到 master/main，并触发 CI/CD 流水线完成部署。
4. 量化策略版本管理的特殊实践
策略版本与数据版本解耦： 策略代码版本号仅反映逻辑变更。数据源版本（如因子数据快照日期）应单独记录在配置文件中，避免因数据重跑导致策略版本号频繁变更。
- 参数版本化： 将策略参数（如止损阈值、仓位比例）与代码版本解耦，使用独立的参数配置文件或参数服务管理。
- 回测版本标记： 每次回测结果应记录策略版本号、数据版本号与参数版本号，形成完整的可复现三元组。
- 灰度发布： 对于实盘策略，建议先在小资金账户或模拟盘部署新版本，观察 PSI 漂移与收益表现后再全量发布。