流程版本基础概念
讲流程版本变更，有个前提你得先搞清楚——版本到底是怎么命名的，基线是干嘛的，快照又是什么东西。我在团队里经常看到新人一上来就乱打 tag，结果回溯的时候连自己都找不着北。这一节咱们就把这三个基础概念掰扯清楚。
1. 版本号规范
版本号不是随便写的。我个人习惯用语义化版本号（SemVer），格式很简单：MAJOR.MINOR.PATCH。
版本号格式：<主版本>.<次版本>.<修订号> [ -预发布号 ]
示例：
1.0.0 —— 初始正式版
1.0.1 —— 缺陷修复版
1.2.0 —— 新增特性，向下兼容
2.0.0 —— 不兼容的重大变更
2.1.0-alpha.1 —— 内部测试版为什么强调这个？因为你做流程版本变更分析时，报告里会频繁引用这些编号。如果一个版本号看不出任何语义，你回头分析的时候就只能靠猜。
主干分支版本策略（我建议的用法）：
master分支只打正式版M.m.p，例如2.1.0。- 开发分支打成
M.m.p-SNAPSHOT，例如2.2.0-SNAPSHOT。 - Hotfix 打
M.m.p+hotfix-xxx，方便识别紧急修复。
这样你拿到任意一个版本号，就能判断它是稳定版还是开发中的快照。
2. 基线与快照
这两个词你可能经常听到，但很多人把它们混为一谈。其实区别很大。
快照（Snapshot） —— 一个在特定时间点对配置项状态的复制，可以随时生成、随时丢弃，不要求评审。快照主要用于临时备份、对比或开发阶段的自查。
我在项目中遇到过这样的场景：测试团队抱怨说「这个版本之前测过是好的，现在怎么坏了？」查了半天才发现，他们用的「基线」其实是某次快照，开发人员事后又修改了那个配置项。说白了，就是基线没锁住，快照被当成了基线用。
下表对比了它们的关键差异：
| 特性 | 基线 (Baseline) | 快照 (Snapshot) |
|---|---|---|
| 产生时机 | 里程碑评审通过后 | 任意时刻 |
| 变更控制 | 必须走 CCB 审批 | 无限制，可覆盖 |
| 稳定性 | 高，作为后续工作的参考基准 | 低，仅代表瞬间状态 |
| 生命周期 | 长期保留，不可删除 | 可自动过期清理 |
| 典型用途 | 发布版本、审计证据 | 开发中局部对比、快速回退 |
你想想看，如果一份报告的结果是基于快照而不是基线产生的，那它的可信度就要打个问号。所以我们在流程版本变更分析中，必须明确标注每条结果来源是基线还是快照。
3. 配置项标识
配置项（Configuration Item, CI）是你版本管理的最小单元。一个流程版本可能包含几十上百个配置项——代码文件、数据库脚本、配置文件、参数模板……每个配置项必须有一个唯一标识，否则你根本没法追踪变更影响。
配置项标识通常遵循 CI_ID + 版本号 的规则：
配置项标识示例：
CI-TYPE-CONF_001 v1.2.0
CI-TYPE-SCRIPT_042 v2.0.1
CI-TYPE-TPL_007 v1.0.0-SNAPSHOT其中 CI-TYPE 可以自定义，我一般用：
CONF—— 配置文件SCRIPT—— 脚本文件TPL—— 模板文件DB—— 数据库脚本
标识里最好包含版本号，这样你从报告里看到 CONF_001 v1.2.0，就能立刻定位到具体的配置项版本。
3F2504E0-4F89-41D3-9A0C-0305E82C3301——这玩意儿在报告里完全没法看。后来我强制改成 PROJ-CONF-001 v1.2.0 这种人类友好的格式，团队效率明显提升。
好，这三个概念串起来，整个流程版本管理的骨架就出来了。下面这张图可以帮你快速理解它们的关系。
看到这张图你可能会问：基线、快照和版本号之间怎么在实际中协作？举个例子：
- 项目团队开发到某个阶段，所有配置项符合要求，由评审委员会通过后，系统自动生成一个基线版本，版本号定为
1.0.0。 - 同时，持续集成服务器每小时会打一个快照，版本号统一为
1.0.0-SNAPSHOT-20250315-1615（含时间戳）。 - 每个快照里的配置项标识都明确标注了快照版本，例如
DB_001 v1.0.0-SNAPSHOT-20250315-1615。 - 如果后续发现某个变更影响了报告结果，你可以用基线版本重跑验证，也可以对比不同快照之间的差异。
记住：基线是「锚」，快照是「镜」，配置项标识是「钥匙」。这三者编好了，你的版本变更分析才有扎实的数据基础。