1. 版本管理基础
大家好，我是这次课程的主讲。在正式开始讲配方版本对比与回滚之前，我觉得有必要先聊聊最基础的东西——版本管理。
你可能觉得这很简单，不就是给配方编个号吗？其实不然。我在好几个项目里都见过因为版本混乱导致的线上事故。有一次，生产线的操作员拿错了配方版本，一批产品直接报废，损失几十万。从那以后，我对版本管理的敬畏心就特别重。
为什么需要版本管理
说白了，版本管理就是为了解决三个问题：
- 知道当前用的是哪个版本 —— 避免用错
- 知道之前改过什么 —— 方便追溯
- 能回到之前的某个版本 —— 出问题能回滚
你想想看，如果没有版本管理，配方文件可能就叫“配方_最终版”、“配方_最终版2”、“配方_最终版3_千万别改”。这种命名方式，我见过太多次了。每次看到都觉得头大。
核心观点：版本管理不是束缚，而是保护。它保护你的配方不被误改，保护你的生产不中断，保护你的团队不背锅。
在配方管理这个领域，版本管理尤其重要。因为配方直接决定了产品质量。一个参数调错了，整批产品可能就不合格。我记得有个做化工的朋友跟我说，他们有一次因为配方版本没对齐，结果生产出来的胶水粘性不对，客户直接退货。
配方版本的核心概念
配方版本管理，跟代码版本管理有点像，但又不完全一样。我总结了一下，有几个核心概念你必须搞清楚：
| 概念 | 说明 | 我的经验 |
|---|---|---|
| 配方快照 | 某个时间点配方的完整状态 | 每次发布前必须打快照，这是回滚的基础 |
| 版本号 | 唯一标识一个配方版本的字符串 | 建议用语义化版本，后面会细讲 |
| 变更记录 | 记录每次修改了什么、谁改的、为什么改 | 这个最容易忽略，但出问题时就靠它了 |
| 基线版本 | 经过验证、可以用于生产的稳定版本 | 我习惯把基线版本锁定，不允许随意修改 |
| 草稿版本 | 正在开发中、尚未发布的版本 | 草稿版本可以随便改，但发布前必须评审 |
小提示：我个人习惯把配方版本跟物料批次号关联起来。这样一旦某个批次出问题，能快速定位到当时用的是哪个配方版本。
嗯，这里要注意一点：配方版本跟代码版本有个很大的不同。代码版本可以频繁发布，一天发几十次都行。但配方版本不一样，它直接影响生产，所以发布节奏要稳。我建议配方版本不要频繁变动，除非有明确的优化需求或者问题修复。
版本号命名规范（语义化版本）
版本号怎么定？这是个好问题。我见过各种各样的命名方式：V1.0、V2.0、20240101、1.0.0.1……说实话，只要团队内部统一，都能用。但我个人强烈推荐使用语义化版本。
语义化版本，说白了就是 主版本号.次版本号.修订号 这种格式。它的规则很简单：
- 主版本号：做了不兼容的修改时递增。比如配方结构变了、关键参数范围变了。
- 次版本号：做了向下兼容的功能性新增时递增。比如新增了一个可选参数。
- 修订号：做了向下兼容的问题修正时递增。比如修复了一个参数计算错误。
举个例子：
1.0.0 → 初始版本
1.0.1 → 修复了温度参数的单位转换错误
1.1.0 → 新增了湿度补偿功能
2.0.0 → 重构了配方结构，不再兼容旧版本为什么会这样设计？因为通过版本号，你一眼就能看出这个版本的变化有多大。1.0.1 到 1.0.2，只是小修小补，放心升级。但 1.0.0 到 2.0.0，那就要慎重了，可能涉及重大变更。
警告：我曾经在一个项目里遇到过团队把版本号乱用的情况。明明只是改了个参数描述，却把主版本号从 1 升到了 2。结果下游系统以为配方结构变了，直接报错。所以，版本号一定要按规范来，不要随意升级。
除了标准的三个数字，语义化版本还支持预发布版本号和构建元数据。比如 1.0.0-alpha.1、1.0.0+build.20240101。这些在配方管理里也很有用：
- 预发布版本：用于测试环境验证，比如
2.0.0-beta.1 - 构建元数据：可以带上日期或者构建编号，方便追溯
下面这张图，是我整理的一个配方版本管理知识体系，你可以看看：
最后，我想强调一点：版本号一旦发布，就不能修改。如果你发现某个版本有问题，正确的做法是发布一个新版本，而不是去修改已经发布的版本。这是版本管理的底线。
我的习惯：每次发布新版本前，我都会在变更记录里写清楚：改了哪里、为什么改、影响范围是什么。这样即使过了半年，回头看也能一目了然。
好了，版本管理的基础就讲到这里。这些概念虽然简单，但它们是后面所有操作的基础。你想想看，如果连版本号都搞不清楚，怎么对比版本？怎么回滚？所以，这一章的内容，值得你花点时间消化一下。