版本控制（Git）在可重复计算中的作用
好，咱们直接切主题。版本控制这玩意儿，早就不只是写代码的时候用了。在可重复计算这个领域，Git 可以说是“第一个也是最后一个”的协同锚点。你想想看，没有版本控制，你的实验副本会变成「最终版」「最终版2」「最终版3_final_really」，最后连谁改了参数都不知道。我入行第三年就吃过这个亏。
为什么版本控制对可重复计算至关重要
可重复计算的核心是「任意时刻都能重建出当时的状态」。Git 正是为此而生的。它不只能帮你回溯代码，还能配合 Git LFS、DVC 这类工具追踪数据和模型。我习惯把 Git 当作“实验元数据”的硬核笔记本——每次提交都记录做了什么、为什么做、结果长什么样。
说白了，没有版本控制的实验，就像没有坐标的海图。你只能靠记忆和经验航行，一旦翻船，连回退都找不到方向。
关键实践：追踪数据、代码、配置
一套完整的可重复计算工作流，需要同时管理三类对象：
- 代码 —— 分析脚本、训练脚本、测试脚本
- 数据 —— 原始数据、预处理中间体、特征文件
- 配置 —— 超参数、模型结构定义、环境依赖
代码自然用 Git 标准操作。数据呢？直接用 Git 存大文件会炸掉仓库。我的做法是：用 git-lfs 或者 DVC（Data Version Control）把数据指针存进 Git，实际数据存到对象存储或本地. 配置则建议写成 YAML/JSON 文件，一起纳入版本管理。
这样，一次 checkout 就能拉下代码 + 配置 + 数据指针，然后通过 DVC pull 还原数据。整个过程是
git clone git@github.com:user/repo.git
cd repo
dvc pull
python train.py --config config/experiment_001.yaml你有没有发现？这个过程里没有任何“手动复制”。这就是可重复的魅力。
使用 Git 进行实验追踪
每次实验开始前，我会创建一个新的分支或 tag。命名规则是这样：
| 元素 | 示例 |
|---|---|
| 实验编号 | exp-007 |
| 算法变体 | exp-resnet50 |
| 版本标记 | v1.0 |
| 完整 tag | exp-007-resnet50-v1.0 |
然后执行一次干净的训练流程。训练结束后，立刻用 git tag 打上标记。我曾经在一个月后需要复现某次验证集的奇怪结果，就是靠这个 tag 直接切回去再跑一遍的——除了系统库版本可能不同，其他完全一致。
git add .
git commit -m "exp-007 resnet50 lr=0.001, aug=True"
git tag -a exp-007-resnet50-v1.0 -m "实验结果: val_acc=0.892, loss=0.23"为什么要提交时写实验结果？因为 Git log 里能直接看到结果概览，不需要再翻 notebook 或日志。我个人习惯把关键指标直接放到 commit message 或 tag annotation 里。
git notes 挂载实验报告或图表的文本摘要，不污染 commit 消息，但能随时查看。
Git 与容器/Docker 结合
有一类常见问题：代码没变，但系统库升级了，结果跑出来不一样。你怪谁？怪自己没锁环境。
做法很简单：把 Dockerfile 或 requirements.txt 也纳入版本管理。我的项目里通常有一个 env/ 目录，里面放着不同实验环境的描述文件。commit 前确保环境文件已经更新。
env/
├── base_ubuntu.Dockerfile
├── exp-007_cuda11.8.Dockerfile
└── exp-007_env.yaml这样，任何人 checkout 到某次实验的 commit，都能用对应的 Dockerfile 构建一模一样的环境，连系统包版本都对得上。嗯，这里要注意：Docker image 本身太大，Git 不存；只存构建脚本，镜像由 CI/CD 或手动构建。
pip freeze 结果加到仓库，结果两个月后复现时发现某依赖有大版本升级，导致预处理逻辑行为变了。从那以后，我再也不敢让环境文件脱离版本控制。
Git 在团队协作中的可重复性
团队里人多手杂，最容易出现“我改了参数，但忘记告诉你”的情况。我要求团队成员必须遵循一条纪律：任何改动都必须对应一个 Git commit，且 commit 里明确写出改动理由。
分享一个简单的工作流：
- 每个实验独立分支（或 tag）
- 实验完成后，merge 到主分支时保留实验分支的 tag
- 所有衍生结果（日志、模型权重、图表）不存入 Git，而是通过脚本在 CI 里重建后自动上传到共享存储
为什么结果不存 Git？因为实验过程中会产生大量中间文件，Git 根本扛不住。而且结果本身是“可推导”的——只要代码、数据、配置和种子都对，就能重新生成。Git 应当只存储“不可推导”的源头。
一张图总结版本控制与可重复计算的关系
下面的 SVG 展示了从原始输入到可复现输出的核心链路，Git 在其中扮演“快照管理器”的角色。
常见陷阱与避坑指南
另外，我见过不少新人把 __pycache__、.ipynb_checkpoints、日志文件夹一股脑加入仓库。这些垃圾文件不但不影响可重复性，还污染历史。解决方案很简单：项目根目录放一个 .gitignore，把所有生成物全屏蔽。
# .gitignore 示例
__pycache__/
*.pyc
.ipynb_checkpoints/
logs/
results/
checkpoints/
*.pt
*.pth
*.h5
data/raw/*.csv
data/processed/*.parquet最后我再啰嗦一句：commit message 一定要有信息量。别写“update”“fix bug”，要写“exp-007: 调整学习率 0.01→0.001, 验证集准确率提升 2.3%”。这样一年后翻历史时，你还能看懂当时的决策。