4、配方版本管理策略：分支策略、标签管理与发布流程、配方回滚与灾难恢复
配方管理做到一定规模，你就会发现一个尴尬的事实：配方本身不是问题，配方的变化过程才是。我见过太多团队，配方文件散落在共享文件夹里，文件名后面跟着「_最终版」「_最终版2」「_真不改了」。这种搞法，出一次质量事故就能让你查三天三夜。
这一章，我们聊聊正经的版本管理策略。说白了，就是怎么管住配方的每一次变化，让回滚和发布变得可控。
4.1 分支策略：Git Flow vs Trunk Based
分支策略决定了团队怎么协作。我个人的经验是：没有银弹。选哪种，取决于你的团队规模、发布频率和风险承受能力。
4.1.1 Git Flow：适合严谨的制造场景
Git Flow 把分支分成了几类：main（主分支）、develop（开发分支）、feature（功能分支）、release（发布分支）、hotfix（热修复分支）。
我在一家精密化工企业遇到过这种情况：配方变更需要经过实验室小试、中试验证、试生产、正式量产四个阶段。每个阶段都要审批，不能乱跳。Git Flow 正好匹配这种流程。
- 从
develop拉出feature/配方A-优化 - 开发测试完成后，合并回
develop - 准备发布时，从
develop拉出release/v2.1.0 - 在
release分支上只做 bug 修复，不做新功能 - 验证通过后，合并到
main并打标签 - 同时合并回
develop，保持同步
优点很明显：流程清晰，责任明确。缺点呢？分支太多，合并频繁，小团队容易觉得累赘。
4.1.2 Trunk Based：适合快速迭代
Trunk Based 就简单多了。所有开发都在 main（或 trunk）上进行。分支存在时间不超过几天。说白了，就是「小步快跑，频繁提交」。
我后来带的一个食品配方团队就用这个。因为他们的配方变更往往只是调整某个香精的千分之几，改完马上就能试产。没必要搞复杂的分支树。
- 团队 < 5 人，发布频率高（每天多次）→ Trunk Based
- 团队 > 10 人，有严格的审批和发布窗口 → Git Flow
- 中间状态 → 可以考虑 GitHub Flow 或 GitLab Flow，折中方案
4.1.3 两种策略对比
| 维度 | Git Flow | Trunk Based |
|---|---|---|
| 分支数量 | 多（长期存在多个分支） | 少（几乎只有 main） |
| 发布频率 | 低（按版本发布） | 高（持续发布） |
| 冲突风险 | 低（隔离性好） | 高（需要频繁同步） |
| 适合场景 | 合规要求高、审批流程长 | 快速试错、小团队 |
| 学习成本 | 高 | 低 |
4.2 标签管理与发布流程
分支管的是「过程」，标签管的是「节点」。每次发布正式配方，都应该打一个标签。这就像给配方拍了一张快照，以后想回看哪个版本，直接找标签就行。
4.2.1 标签命名规范
我见过最乱的标签命名：v1、v2、配方最终版、20240101。这种命名方式，三个月后你自己都分不清。
我建议用语义化版本号：v主版本.次版本.修订号
- 主版本：配方体系发生重大变更（如更换了核心原料）
- 次版本：配方功能增强或参数调整（如优化了某个助剂比例）
- 修订号：bug 修复或微小调整（如修正了某个计量单位错误）
v2.1.0 # 主版本2，次版本1，修订号0
v2.1.1 # 修复了v2.1.0中的一个计算错误
v3.0.0 # 更换了基础油，配方体系重构4.2.2 发布流程
发布不是简单打个标签就完事。我踩过这个坑：有一次直接在生产分支上打了标签，结果发现配方文件里有个参数写错了。但标签已经打了，改起来很麻烦。
正确的发布流程应该是：
- 代码冻结：在发布分支上停止新功能开发
- 最终验证：运行所有配方测试用例，检查参数范围
- 打标签：使用
git tag -a v2.1.0 -m "配方A v2.1.0 发布说明" - 推送标签：
git push origin v2.1.0 - 发布通知：通知生产、质量、仓库等相关部门
4.3 配方回滚与灾难恢复
配方出问题，最坏的情况是什么？生产线上正在用错误的配方批量生产，产品全部报废。这时候，回滚能力就是救命稻草。
4.3.1 回滚策略
回滚分两种：
- 局部回滚：只回滚某个配方文件到历史版本
- 全局回滚：整个配方库回滚到某个发布版本
我建议优先用局部回滚。为什么？因为全局回滚影响面太大，可能把其他配方的正确变更也回滚掉了。
# 查看某个文件的历史版本
git log --oneline -- 配方A.yaml
# 回滚到指定提交
git checkout <commit-hash> -- 配方A.yaml
# 提交回滚
git commit -m "回滚配方A到v2.0.0版本"4.3.2 灾难恢复计划
我曾经遇到过一次仓库损坏的情况。当时团队用的 Git 服务器硬盘坏了，虽然最后通过异地备份恢复了，但整整耽误了两天生产。
从那以后，我强制要求每个配方项目都要有灾难恢复计划：
| 恢复等级 | 恢复时间目标 | 恢复点目标 | 方案 |
|---|---|---|---|
| L1（热备） | < 1 小时 | 丢失 < 1 小时数据 | 主仓库 + 实时镜像仓库 |
| L2（温备） | < 4 小时 | 丢失 < 1 天数据 | 每日全量备份 + 异地存储 |
| L3（冷备） | < 24 小时 | 丢失 < 1 周数据 | 每周全量备份 + 离线归档 |
git bundle 命令做离线备份，每周把整个仓库打包成一个文件，存到不同的物理位置。
4.4 知识结构图
下面这张图，把配方版本管理的核心逻辑串起来了。你一看就明白：分支策略管过程，标签管节点，回滚管异常。
嗯，这张图把整个流程串起来了。你从左边开始看：开发阶段选好分支策略，发布时打标签，出问题时回滚。环环相扣，缺一不可。