3. 版本管理基础
在自动驾驶数据版本管理与可追溯工程中，版本管理并不是“把文件存起来”这么简单。它要回答四个关键问题：当前用的是哪一版数据、这版数据从哪里来、谁在什么时间改了什么、出现问题时能否回到已知可用状态。围绕这四个问题，版本、分支、标签、提交、合并与冲突解决构成了最基础的概念体系。理解它们，才能把数据集、标注、模型配置、感知算法参数和评测脚本纳入同一套可追溯链路。
一、核心对象：提交是版本演进的原子单位
在 Git 或类 Git 的版本管理系统中，提交（commit）是版本演进的最小原子单位。一次提交通常记录：父提交指针、作者与时间、提交说明、以及本次变更的快照或差异。对于自动驾驶数据工程，提交可以代表“新增 1200 帧城市道路标注”“修正 37 个漏标行人框”“更新感知模型训练配置”等具体动作。
版本（version）是某一时刻的完整状态，通常由提交 ID、标签或发布号标识。分支（branch）是一条可独立演进的提交线，用于并行开发、实验或数据修复。标签（tag）是指向某个提交的不可变命名引用，常用于标记“数据集 v1.2 发布”“模型基线 2024-06-01”等关键节点。它们的关系可以用下面的结构图表示。
二、方法流程：从提交到合并的标准动作
在自动驾驶数据项目中，推荐把版本管理动作固化为以下流程：
- 创建分支：从稳定主干切出
feature/xxx或fix/xxx，避免直接在主干预发布数据。 - 小步提交：每次提交只做一件事，提交说明写清“改了什么数据、影响哪些场景、关联哪个任务”。
- 推送与评审：将分支推送到远端，发起合并请求，由数据质检或算法负责人评审。
- 合并：评审通过后合并到主干，必要时使用压缩合并保持历史清晰。
- 打标签：对发布版本打上不可变标签，如
dataset-v1.2.0。
下面是一组常用命令示例，可用于数据仓库或代码仓库的日常操作：
# 从主干创建标注修复分支
git checkout main
git pull origin main
git checkout -b fix/annotation-pedestrian
# 修改标注文件后提交
git add annotations/city_001.json
git commit -m "fix: 修正 city_001 中 37 个漏标行人框"
# 推送并创建合并请求
git push origin fix/annotation-pedestrian
# 合并完成后打标签
git checkout main
git merge --no-ff fix/annotation-pedestrian
git tag -a dataset-v1.2.0 -m "发布城市道路数据集 v1.2.0"
git push origin main --tags三、案例场景：数据标注修复中的分支与合并
假设某自动驾驶团队发现城市道路数据集中，city_001 场景存在行人漏标。标注组从 main 切出 fix/annotation-pedestrian 分支进行修复；与此同时，算法组在 feature/new-augmentation 分支上调整了同一批图片的增强参数。两条分支都修改了 city_001 的元数据文件，合并时就会产生冲突。
此时不能简单“选一边”。正确做法是：先查看冲突文件，确认标注修复与增强参数是否互相依赖；若互不冲突，则保留双方修改并重新生成校验和；若冲突涉及同一字段，则需由数据负责人裁定，并在提交说明中记录决策依据。这样，最终合并提交既包含修复，也包含参数更新，且可追溯。
四、误区与复盘：常见问题与对照表
初学者常把“版本管理”等同于“备份”，导致分支混乱、标签缺失、冲突处理随意。以下对照表列出常见误区与推荐做法。
| 概念 | 常见误区 | 推荐做法 |
|---|---|---|
| 提交 | 一次提交混入多个不相关修改 | 小步提交，说明写清数据范围与任务编号 |
| 分支 | 所有人直接在 main 上改 | 按功能/修复切分支，评审后合并 |
| 标签 | 用分支名代替发布版本 | 发布时打不可变标签，如 dataset-v1.2.0 |
| 合并 | 冲突时随意删除一方代码 | 理解双方意图，保留有效修改并记录决策 |
| 冲突解决 | 不测试直接提交合并结果 | 合并后运行数据校验与回归评测 |
总结来看，版本管理基础可以浓缩为一句话：提交记录变化，分支隔离并行，标签锁定发布，合并整合成果，冲突解决保证语义正确。只有把这五个概念落到自动驾驶数据与模型资产的实际操作中，后续的数据追溯、回滚和审计才有可靠基础。