无论是研究、数据科学还是软件工程，追踪您或合作者对数据和软件所做的更改，都是任何项目的关键环节。能够引用或取回整个项目的特定版本，有助于在发表前的可复现性、回应审稿人意见时，以及为审稿人、编辑和读者提供支持性信息时发挥作用。
最适合追踪更改的工具，是软件开发中使用的版本控制系统，如 Git、Mercurial 和 Subversion。它们记录文件在何时、由谁修改了什么，并将更改同步到中央服务器，使多位贡献者能够共同管理同一组文件的变更。
尽管这些工具让变更追踪更容易，但它们的学习曲线可能很陡。为了克服这一点，我们提供两套建议：一种是系统化的手动变更管理方法，另一种是完整使用版本控制。您可以先采用第一种方法，逐步过渡到第二种，或直接使用版本控制。
版本控制的最佳实践
无论您最终选择哪种建议，都有一些通用的最佳实践或建议值得遵循：
尽早备份（几乎）所有由人创建的内容。 这包括各类脚本和程序、项目所依赖的软件包，以及文档。对此规则的少数例外将在下文讨论。
把更改做小。 每次更改不应大到让变更追踪失去意义。例如，一次性提交一个如 Revise script file 的更改，新增或修改数百行内容，很可能过大，因为这会妨碍分别检查分析中不同组件的更改。同样，更改也不应被拆分得过小。经验法则是：一次合适的更改规模，应当是一组您未来可能希望在一步操作中撤销的编辑。
频繁共享更改。 项目组的每个人都应定期共享并合入他人的更改。不要让各研究者各自的项目仓库版本彼此偏离，因为合并差异所需的工作量会比差异本身的大小增长得更快。对于下文所述的手动版本方法，这一点尤为重要，因为该方法对同时、且可能冲突的更改不提供任何合并辅助。
为保存与共享项目更改创建、维护并使用检查清单。 清单应包含撰写清晰说明更改内容的日志信息、单次更改的规模与内容、代码风格指南、更新待办事项清单，以及禁止提交未完成的工作或损坏的代码等。
将每个项目存放在会从研究者工作机器进行镜像的文件夹中 ，可使用 Dropbox 等系统或 GitHub 等远程代码库。至少每日同步该文件夹。可能会花费几分钟，但一旦笔记本被盗或硬盘损坏，这点时间就会立刻物有所值。
如何进行手动版本管理
第一种建议的方法是全程手动执行，它包含两个补充步骤。
首先，在项目的 docs 子文件夹中添加一个名为 CHANGELOG.txt 的文件，并以逆时间顺序（即最近在前）记录对项目所做更改的带日期说明。该文件相当于实验记录本，应包含如下所示的条目。
## 2016 - 04 - 08
* Switched to cubic interpolation as default .
* Moved question about family's TB history to end of questionnaire.
## 2016 - 04 - 06
* Added option for cubic interpolation.
* Removed question about staph exposure ( can be inferred from blood test results) .
技术支持 其次，每当进行一次重大更改（即实质性影响结果的更改）时，复制整个项目，并将该副本存放在同步区域内以日期命名的子文件夹中。采用此方法后，项目将组织如下：
.
| -- project_name
| -- current
| -- ... project content as described earlier...
| -- 2016 - 03 - 01
| -- ... content of 'current' on Mar 1 , 2016
| -- 2016 - 02 - 19
| -- ... content of 'current' on Feb 19 , 2016
技术支持 其中，project_name 文件夹映射到外部存储（如 Dropbox），current 是当前工作的目录，project_name 内的其他文件夹为旧版本。
手动版本管理的优缺点
人们常说“数据便宜，时间宝贵”。像上述方法那样复制所有内容可能看起来很浪费，因为许多文件并未更改，但请考虑：一块 1TB 的硬盘零售价约为 50 美元，这意味着 50GB 的成本不到 5 美元。只要将大型数据文件排除在备份区域之外（下文将进一步讨论），这种方法的成本低于您手动选择要复制文件所花费的时间。
这种手动流程无需任何新工具即可满足上述要求。但如果有多名研究者在同一项目上工作，则需要协调，确保任一时刻只有一个人在编辑特定文件。尤其是，他们可能希望为每位贡献者创建一个变更日志文件，并在制作备份副本时合并这些文件。
版本控制系统
上述手动流程最需要的是自律。支撑我们第二种方法（也是我们自己项目中使用的方法）的工具，不仅加速了手动流程：它们还会自动化某些步骤，同时对另一些步骤进行约束，从而以更少的自律要求获得更可靠的结果。
很难确切知道当今研究中最广泛使用的工具是什么，但讨论最多的无疑是 Git。这在很大程度上归功于 GitHub，这一流行的托管网站将基于 Git 的协作技术基础设施与现代网页界面结合起来。GitHub 对公共和开源项目，以及学术和非营利用户免费。GitLab 是口碑良好的替代方案，一些人更青睐它，因为 GitLab 平台本身是免费且开源的。Bitbucket 为 Git 和 Mercurial 仓库提供免费托管，但其科研用户数量远不及前两者。
不应纳入版本控制的内容
版本控制系统的优势并不适用于所有文件类型。尤其是，效果会因文件大小与格式而异。
首先，版本控制系统中的文件比较对纯文本文件（如源代码）优化。通常，查看所谓的“差异（diff）”是版本控制的一大乐趣。不幸的是，尽管 Microsoft Office 文件（如 Word 使用的 .docx）或其他二进制文件（如 PDF）可以存储在版本控制系统中，但无法精确定位从一个版本到下一个版本的具体更改。又如表格数据（如 CSV）也可以纳入此类系统，但如果更改了行或列的顺序，即便数据本身未变，也会产生巨大的“更改”。
其次，原始数据不应发生变化，因此也不需要版本追踪。如果可以从原始数据和软件重新生成中间数据文件及其他结果，就没有必要将它们纳入版本控制。不过，如果数据和结果很小，建议将其纳入版本控制，以便合作者访问并便于跨版本比较。
第三，当今的版本控制系统并非为处理数兆字节级别（更不用说数吉字节）的文件而设计，因此不应包含大型数据或结果文件。（作为“大型”的参考标准，GitHub 对单个文件的限制为 100MB。）一些新兴的混合系统（如 Git LFS）会将文本记录纳入版本控制，同时把大型数据本身存储在远程服务器，但这些方案尚未成熟到足以推荐。
意外共享
另一个版本控制系统优势难以发挥的情形是“意外共享”。处理受法律限制、禁止共享的数据（如医疗数据）的研究人员，应谨慎避免将数据放入公共版本控制系统。一些机构可能提供私有系统的访问权限，建议向您所在机构的 IT 部门咨询。
此外，请务必避免将密码、私钥等安全凭据无意间放入版本控制系统，从而可能被他人访问。
如果您想尝试上述内容，欢迎查看我们为数据科学准备的 Git 入门免费课程 。
致谢
本文摘自 Greg Wilson、Jennifer Bryan、Karen Cranston、Justin Kitzes、Lex Nederbragt 和 Tracy K. Teal 的 "Good enough practices in scientific computing"，https://doi.org/10.1371/journal.pcbi.1005510 。
无论是研究、数据科学还是软件工程，追踪您或合作者对数据和软件所做的更改，都是任何项目的关键环节。能够引用或取回整个项目的特定版本，有助于在发表前的可复现性、回应审稿人意见时，以及为审稿人、编辑和读者提供支持性信息时发挥作用。
最适合追踪更改的工具，是软件开发中使用的版本控制系统，如 Git、Mercurial 和 Subversion。它们记录文件在何时、由谁修改了什么，并将更改同步到中央服务器，使多位贡献者能够共同管理同一组文件的变更。
尽管这些工具让变更追踪更容易，但它们的学习曲线可能很陡。为了克服这一点，我们提供两套建议：一种是系统化的手动变更管理方法，另一种是完整使用版本控制。您可以先采用第一种方法，逐步过渡到第二种，或直接使用版本控制。
版本控制的最佳实践
无论您最终选择哪种建议，都有一些通用的最佳实践或建议值得遵循：
尽早备份（几乎）所有由人创建的内容。这包括各类脚本和程序、项目所依赖的软件包，以及文档。对此规则的少数例外将在下文讨论。
把更改做小。每次更改不应大到让变更追踪失去意义。例如，一次性提交一个如
Revise script file的更改，新增或修改数百行内容，很可能过大，因为这会妨碍分别检查分析中不同组件的更改。同样，更改也不应被拆分得过小。经验法则是：一次合适的更改规模，应当是一组您未来可能希望在一步操作中撤销的编辑。频繁共享更改。项目组的每个人都应定期共享并合入他人的更改。不要让各研究者各自的项目仓库版本彼此偏离，因为合并差异所需的工作量会比差异本身的大小增长得更快。对于下文所述的手动版本方法，这一点尤为重要，因为该方法对同时、且可能冲突的更改不提供任何合并辅助。
为保存与共享项目更改创建、维护并使用检查清单。清单应包含撰写清晰说明更改内容的日志信息、单次更改的规模与内容、代码风格指南、更新待办事项清单，以及禁止提交未完成的工作或损坏的代码等。
将每个项目存放在会从研究者工作机器进行镜像的文件夹中，可使用 Dropbox 等系统或 GitHub 等远程代码库。至少每日同步该文件夹。可能会花费几分钟，但一旦笔记本被盗或硬盘损坏，这点时间就会立刻物有所值。
如何进行手动版本管理
第一种建议的方法是全程手动执行，它包含两个补充步骤。
首先，在项目的
docs子文件夹中添加一个名为CHANGELOG.txt的文件，并以逆时间顺序（即最近在前）记录对项目所做更改的带日期说明。该文件相当于实验记录本，应包含如下所示的条目。其次，每当进行一次重大更改（即实质性影响结果的更改）时，复制整个项目，并将该副本存放在同步区域内以日期命名的子文件夹中。采用此方法后，项目将组织如下：
其中，
project_name文件夹映射到外部存储（如 Dropbox），current是当前工作的目录，project_name内的其他文件夹为旧版本。手动版本管理的优缺点
人们常说“数据便宜，时间宝贵”。像上述方法那样复制所有内容可能看起来很浪费，因为许多文件并未更改，但请考虑：一块 1TB 的硬盘零售价约为 50 美元，这意味着 50GB 的成本不到 5 美元。只要将大型数据文件排除在备份区域之外（下文将进一步讨论），这种方法的成本低于您手动选择要复制文件所花费的时间。
这种手动流程无需任何新工具即可满足上述要求。但如果有多名研究者在同一项目上工作，则需要协调，确保任一时刻只有一个人在编辑特定文件。尤其是，他们可能希望为每位贡献者创建一个变更日志文件，并在制作备份副本时合并这些文件。
版本控制系统
上述手动流程最需要的是自律。支撑我们第二种方法（也是我们自己项目中使用的方法）的工具，不仅加速了手动流程：它们还会自动化某些步骤，同时对另一些步骤进行约束，从而以更少的自律要求获得更可靠的结果。
很难确切知道当今研究中最广泛使用的工具是什么，但讨论最多的无疑是 Git。这在很大程度上归功于 GitHub，这一流行的托管网站将基于 Git 的协作技术基础设施与现代网页界面结合起来。GitHub 对公共和开源项目，以及学术和非营利用户免费。GitLab 是口碑良好的替代方案，一些人更青睐它，因为 GitLab 平台本身是免费且开源的。Bitbucket 为 Git 和 Mercurial 仓库提供免费托管，但其科研用户数量远不及前两者。
不应纳入版本控制的内容
文件大小与格式
版本控制系统的优势并不适用于所有文件类型。尤其是，效果会因文件大小与格式而异。
首先，版本控制系统中的文件比较对纯文本文件（如源代码）优化。通常，查看所谓的“差异（diff）”是版本控制的一大乐趣。不幸的是，尽管 Microsoft Office 文件（如 Word 使用的
.docx）或其他二进制文件（如 PDF）可以存储在版本控制系统中，但无法精确定位从一个版本到下一个版本的具体更改。又如表格数据（如 CSV）也可以纳入此类系统，但如果更改了行或列的顺序，即便数据本身未变，也会产生巨大的“更改”。其次，原始数据不应发生变化，因此也不需要版本追踪。如果可以从原始数据和软件重新生成中间数据文件及其他结果，就没有必要将它们纳入版本控制。不过，如果数据和结果很小，建议将其纳入版本控制，以便合作者访问并便于跨版本比较。
第三，当今的版本控制系统并非为处理数兆字节级别（更不用说数吉字节）的文件而设计，因此不应包含大型数据或结果文件。（作为“大型”的参考标准，GitHub 对单个文件的限制为 100MB。）一些新兴的混合系统（如 Git LFS）会将文本记录纳入版本控制，同时把大型数据本身存储在远程服务器，但这些方案尚未成熟到足以推荐。
意外共享
另一个版本控制系统优势难以发挥的情形是“意外共享”。处理受法律限制、禁止共享的数据（如医疗数据）的研究人员，应谨慎避免将数据放入公共版本控制系统。一些机构可能提供私有系统的访问权限，建议向您所在机构的 IT 部门咨询。
此外，请务必避免将密码、私钥等安全凭据无意间放入版本控制系统，从而可能被他人访问。
如果您想尝试上述内容，欢迎查看我们为数据科学准备的 Git 入门免费课程。
致谢
本文摘自 Greg Wilson、Jennifer Bryan、Karen Cranston、Justin Kitzes、Lex Nederbragt 和 Tracy K. Teal 的 "Good enough practices in scientific computing"，https://doi.org/10.1371/journal.pcbi.1005510。