3. 版本控制基础

在实验数据管理中，版本控制并不是软件工程的专属工具，而是一套用于回答“这份数据从哪来、改了什么、能否复现、哪一版可用于分析”的语义体系。要真正用好它，必须先厘清六个核心概念：版本、修订、分支、标签、快照、基线。它们在实验数据语境下与代码仓库中的含义既有重叠，也有明显差异。

版本与修订：从“第几次”到“改了什么”

版本是对实验数据某一状态的完整标识，通常由版本号、时间戳、操作者和内容摘要共同确定。例如 EXP-2024-0317_v2 表示 2024 年 3 月 17 日实验的第二版数据。版本号本身只是索引，真正决定其语义的是修订——即相邻版本之间发生的具体变更。修订可以是一次传感器校准参数调整、一批异常值剔除、一次采样频率重设，也可以只是元数据补录。

在实验数据中，修订必须可追溯。假设某次光谱实验原始采集 1200 条记录，第一版直接入库；第二版剔除了信噪比低于 15 dB 的 87 条记录，并将积分时间从 100 ms 改为 200 ms。那么 v1→v2 的修订说明应至少包含：剔除条件、剔除数量、参数变更前后值、操作时间与操作人。缺少这些信息，版本号就退化为无意义的数字。

分支：并行实验路径的隔离与汇合

分支是从某个版本派生出的独立演进线。在实验场景中，分支常用于并行尝试不同处理方案而不互相污染。例如从原始数据 v1 分出两条分支：branch-baseline 只做去噪，branch-calibrated 先做波长校准再去噪。两条分支各自产生修订，最终可选择合并或分别归档。

分支的关键语义是隔离与可汇合。隔离意味着一条分支上的修改不会自动影响另一条；可汇合意味着当两条分支需要统一时，系统能识别共同祖先并处理冲突。实验数据中常见的冲突包括：同一时间戳被两条分支赋予不同标签、同一参数被改成不同值。此时不能简单覆盖，而应记录冲突解决依据。

标签与快照：给关键状态起名字、拍照片

标签是指向某个版本的不可变别名，通常用于标记关键节点，如 raw、qc-passed、paper-fig3。标签与版本号的区别在于：版本号会随新修订递增，而标签一旦打上就固定指向某一确定状态。实验数据中，标签应尽量表达业务含义而非序号，例如用 calibration-approved 而不是 tag1。

快照是某一时刻全部相关数据的完整副本或一致性引用。与标签不同，快照强调“完整性”——它不仅记录某个文件的状态，还记录该状态下所有依赖项（原始数据、处理脚本、参数文件、环境说明）的组合。实验数据快照的典型结构如下：

snapshot_2024-03-17T14:30Z/
├── raw/spectrum_001.csv
├── processed/spectrum_001_denoised.csv
├── params/calibration.json
├── scripts/denoise.py
└── manifest.yaml   # 记录各文件哈希与版本号

快照的价值在于可复现：只要拿到快照，就能在任意时间重建当时的分析结果。标签告诉你“这是哪个版本”，快照告诉你“这个版本完整包含什么”。

基线：被正式确认的参照状态

基线是经过评审或确认、后续变更必须以其为参照的版本状态。它通常由“快照 + 标签 + 审批记录”共同构成。例如实验数据在完成质量控制后，将 qc-passed 标签对应的快照正式批准为基线 BL-2024-03-17。此后任何修改都应基于该基线创建新分支，而不是直接改动基线内容。

基线与标签的差别在于治理语义：标签是“命名”，基线是“承诺”。基线一旦确立，就应冻结，只允许通过新版本向前演进。实验数据中，基线常用于以下场景：方法验证完成、论文数据冻结、多中心实验统一口径、监管提交前定版。

六个概念在实验数据中的语义对照

为了便于在实际项目中判断该用哪个概念，下表给出它们在实验数据语境下的核心语义与典型操作：

实际落地时的判断顺序

面对一份实验数据，建议按以下顺序判断该使用哪种版本控制语义：

1. 先问“是否需要复现”：若需要，必须建立快照，记录所有依赖项及其哈希。
2. 再问“是否有并行方案”：若有，创建分支，避免相互覆盖。
3. 然后问“哪个状态是关键节点”：对关键节点打标签，标签名表达业务含义。
4. 最后问“哪个状态需要被正式确认”：对需要评审确认的状态建立基线，冻结并归档审批记录。

理解这六个概念的关键，不在于记住定义，而在于建立“状态—变更—参照”的思维：版本标识状态，修订描述变更，分支隔离变更，标签命名状态，快照固化状态，基线确认参照。实验数据的可复现性、可追溯性与合规性，都建立在这套语义被正确使用的基础之上。