问题提出
谁都不想自己的论文版本乱的一塌糊涂，但现实就是喜欢跟你开玩笑，最终的版本一环套一环很没有条理。
问题分析
计划不如变化快，这很正常。一篇论文中的图表可能要做多个版本而同一版本可能同时多个人给你修改，修回的论文自已可能还要尝试多种修改方法，等最后想把这些东西凑到一个最终版时肯定不是一个轻松愉快的事。所以一个条理清晰的版本控制过程是很有必要的，其实这个问题在科研人员意识到以前就困扰程序员很久了：一个软件如果拆成多个部分去协作或者同一段代码的反复调试与修改都会让开发者不胜其烦，然后就出现了版本控制软件。换句话讲，如果在管理论文时也使用版本控制，那么会不会更方便一些呢？下面我们来看一下一篇典型理工科论文目录下应该有的东西：
- 论文
- 实验计划 - 实验日志 文本格式存储
- 实验原始数据 - excel表格 仪器导出的原始数据 图片
- 探索性数据分析 - 根据原始数据所做的分析 如描述性统计图表 相关分析 主成分分析 rmd文档
- 最终图表 - 论文中出现的图（需要版本控制）pdf 或 jpg
- 实验相关论文 - Endnote library 或 bibtex
- 论文草稿（需要版本控制）doc 或 Rnw
- 论文终稿 doc 或 pdf
仔细想想，如果论文是一盘菜，计划就是菜谱，数据就是原材料，图表是最直观的亮点，最终上桌的那一份跟炒给自己吃的完全不是一个概念。但中间这些半成品是很烦人的，食之无味，弃之可惜，版本控制软件就是来解决这个问题的。
问题解决
先来看看版本控制软件（以git&github为例）的功能：
- 版本控制
这是废话，但该类软件围绕的核心就是解决同一文件不同版本的问题。一般来说，一篇论文会有两条主分支，一条是成品分支，用来提交；另一条是草稿分支，记录论文生成的详细步骤，当草稿修改满意，就可以合并到主分支去发布，发布后有问题可以继续从主分支上跳出到草稿分支继续去修改。事实上，版本控制软件会帮助你记录每一次修改的内容并制作快照，这样不论你想要任何时候的版本或修改的内容都可以在版本控制软件的流程图或历史记录中轻松找到。
- 备份还原
其实到了今天还不用诸如dropbox或skydrive或googledrive的研究僧应该比较少见了，再不济也会每天给自己发个邮件备份一下，但用版本控制软件（以分布式的git为例）备份数据还是有优势的：comment。我现在主要用dropbox，自然研究文件夹也放在上面，借助同步功能，我从不担心数据丢失的问题，但其自带的恢复与还原功能对免费用户而言只能恢复30天内的版本，如果你本地dropbox端同时启用git，每次comment都会有一个快照备份到云端，这样你就可以任意恢复到之前的版本。与网盘的被动备份不同，使用版本控制软件会让你养成主动总结的习惯，每天push到客户端一次并在comment中记录日志会让工作井井有条。还原的话也很简单，在图形界面中浏览修改记录，找到想要回滚的那个镜像切过去就OK了。相信用过虚拟机的对这种快照备份的便捷应该不陌生。
- 分支管理
我并不建议深入研究诸如git，svn详细的命令参数并熟悉命令行操作，他们都有成熟的图形界面，直观易懂。这里有一个简明的教程，而对于仅是拿来用的人而言你只要了解下面几个命令就OK了：
- pull 把服务器端内容拖到本地端
- push 把本地端内容推送到服务端
- add 把当前文件夹内文件加入到版本库里
- tag 在某个主干或分支上任意一点加标签，可通过show命令在标签间快速跳转对比
- branch 在主干上开条分支
- head 把工作节点在主干与不同分支间切换
- merge 把分支合并到主干上
- checkout 容易理解，从某个位置把想要的内容取出编辑，修改完了再comment到版本库里
- comment 每次add或modify后都需要comment提交，comment之后才可以选择push到主干或者分支
其实说白了很简单，主干是按时间走的，分支是平行的。所谓分支管理就是如何把分支的内容裁掉，然后剩下的主干就是你的成品；同时，如果你不想修改主干，只是做一些尝试，可以随时从主干上开个分支单干，也可使随时回滚。这样有了分支主干，版本号什么的就没太有必要了，通过图形界面的节点跳转就可以，还能看到comment。
- 协作修改
其实上面的功能如果你自己有不错的使用习惯都可以简化实现，但一遇到协作问题可能就有问题了，例如张三给你修改了段落a，李四修改了段落b，王五a跟b都修改了，而你只需要最终的一个版本，这时候就麻烦一些了。在git里，你可以通过diff命令去发现不同版本的区别，如果修改的地方不一样，用merge命令可以直接合并这些到一个最终版（例如合并张三与李四的修改）。但如果遇到王五的情况，版本控制软件会提示冲突，这时候就需要使用者自己抉择使用哪个版本，我的建议是先把所有版本都存成分支，然后随机保留其中一个分支到主干，通过diff寻找与另一个分支的不同，把意见合并后修成新版本comment到主干，按照一个一个分支去解决矛盾，当然每解决一个分支都得comment一下到主干，这样最终你只会有一个主干版本，其余的矛盾版本都被记录到版本库的history里去了，可以随时查看修改原因。写到这里你也发现了，对一篇论文提供详尽的修改意见与日志记录就是协作的精髓，因为每个协作者都可以看到并做出新的修改。
另外的问题
不过看到这里很多人可能会奇怪，产生这么多的快照会不会很消耗硬盘空间，其实不会，版本控制软件必然对于压缩有很高的要求，如果你熟悉增量备份的概念，那么这种压缩就不会太成问题。
git可以很好的支持word文档，pdf文档，但如果你的协作者也能接受的话，我更推荐使用RStudio中的knitr包配合自带的git接口与project功能来管理你的论文。通俗的讲，就是用Rnw文档作为草稿文档而输出的pdf作为提交文档，对应的版本管理只针对Rnw文档就可以了，如果你熟悉R与latex排版并用R来给出论文的图表，那么从论文写作到修改，你都可以只控制一个Rnw文档，而且我也建议可重复研究的思想能够在科研界迅速普及，这对科技进步是至关重要的。
写readme文档或日志习惯是很重要的，即使你不打算使用版本管理，那我也建议对特定项目留存日志方便溯源。以写论文为例，实验数据是一方面，文献阅读是另一方面，很多人文献读了不少但一写文章就忘了出处还要重新查询，所以要活用endnote或其他文献管理软件的分类与标签及笔记功能，最好把笔记单独分主题保存为文本文档，摘录出关键点，这样不论你写到哪个部分，想到哪个点就可以在笔记或日志中快速搜索到并溯源。其实这是从资料角度的版本管理，你需要的是看过资料后的感想与启示，这个东西提炼出来资料本身存个档就好了。很多人习惯于在文献上进行标注，只要你回头还查的到也无所谓，但实际情况往往是看过当时很有感触，很快就忘记了，所以把重要的东西提炼成笔记很重要，只要能查到你也没必要去记实际内容。
关于最开始的计划，最好也有个电子版存档，毕竟ctrl + F就能找到关键点，而且对于一个实验室而言，长久的记录实验计划与数据的电子版本身就是一笔财富，我很少去翻都发黄的早期实验记录本，但有电子版的话我会很乐意去提取想要的信息。
结语
其实电脑不是个好东西，他每天占据了你大量的时间，软件就是用来缩短你蹲在屏幕前时间的，如果你能把所有资料整理的井井有条，那么你会有很多时间去发展个人兴趣，回归生活。磨刀不误砍柴工，养成习惯的好处是长久的。