投The BMJ的分析代码天天更新，怎样固定与稿件对应的版本？

投《The BMJ》时，分析仓库每天都在更新。作者在代码共享声明里只贴仓库首页，投稿数周后又修了一个计算函数，结果表却没有重算。编辑若下载当前默认分支，可能无法判断它与稿件对应的是哪一次分析。官网建议 Git 仓库提供提交编号，也要求说明软件和相关库的版本；准备稿件时应把“能找到代码”进一步做到“能定位投稿对应的代码”。

固定投稿对应的版本

在团队确认最后一版数据和结果表之后，记录仓库提交编号、发布日期、分析数据版本和稿件文件版本。若使用归档服务，可保存永久可访问的快照；若仓库设置为私有，先确认编辑和审阅者能否按规则取得必要副本。单写“代码见某平台”会随分支移动而失准，单给压缩包又可能丢失它来自哪次提交。两者可互相印证，而不是任选其一后省掉说明。

检查依赖环境是否有明确的语言、软件版本及包版本。一个名叫 requirements 的文件如果没写版本，也未必能在半年后重建环境；必要时提供锁定文件或逐项记录。脚本中的绝对路径、个人账号、访问令牌应去除。随机数种子、模型参数和外部数据集版本若影响结果，还应与方法段一致。

用一张结果表试运行

选择论文中的一张核心表，请同事在新目录里按说明取得代码、安装依赖并生成对应输出。若因为保密数据不能提供原始表，可用结构相同的测试数据检验程序流程，同时清楚标注这不是复现真实数值。遇到错误要记录是环境、输入文件还是计算逻辑问题；只把报错截图存档，不修复运行条件，无法满足可审查的目的。

若投稿后确实发现代码需要修正，先判断是否改变论文数字。改变结果的修正要同步核对主稿、摘要、图表、补充文件和数据声明，再向编辑说明版本差异；只改仓库而不改稿件，会留下两个互相矛盾的记录。单纯补充注释或修正路径，也应更新版本号，让编辑知道对应关系。

最后的版本清单

提交前给每个主要输出列出脚本路径、提交编号、依赖环境、输入数据版本和核验人。这个清单可用于团队内部复跑与回答编辑询问。若主稿改动使一张图不再出现，也要从共享包说明中更新对应关系，免得读者以为漏交输出。代码不需要写得像商品软件，但应让接手研究的人知道如何从允许访问的数据走到论文结果。保留旧提交编号和核验记录，便于解释修改过程。

参考信息：《The BMJ》“Data and code sharing for research papers in The BMJ”中 Git 提交编号、软件版本和代码可用性说明。