什么是版本控制？

Git 官网 对版本控制是这样解释的：

版本控制是一种记录一个或若干文件内容变化，以便将来查阅特定版本修订情况的系统。

这个解释可能不是太直白，事实上，我们可以把一个版本控制系统（VCS）理解为一个「数据库」，它可以完整地保存一个项目的快照。当需要查看一个之前的快照（称之为「版本」）时，版本控制系统可以显示出当前版本与上一个版本之间所有的改动细节。

为什么要做好版本控制？

很多同学可能都会疑惑：版本控制好麻烦，我真的需要吗？

You never think you need version control until you do......

也许，正如上面这句稍显无奈的话所说，无论我在这里怎么强调版本控制的重要性，都不如你亲身经历一次没有版本控制带来的后果更加有效。版本控制对于管理源代码非常重要，但是对于写作来说，它的观念模式同样适用，也非常重要。版本控制有非常多的好处，对于写作来说，主要体现在下面这几个方面。

方便版本回退

一般来说，写文章尤其是写毕业论文，不是一蹴而就的，会经过一段时间，期间产生多个版本。而我们有时不仅仅需要当前版本，历史版本也是具有价值的。例如，由于操作不当，错误地删除了当前版本的内容，想要回退到上一个版本；写作过程中，觉得之前的版本更好，想要从删除的内容中找回一点灵感，不如从之前的版本开始写。

macOS 的 时间机器（Time Machine）就是一个操作系统级别的版本控制工具，与此同时，macOS 上的很多软件也集成了基本的版本控制，例如 Apple Pages 就具备一定的 版本控制功能，在 Pages 中点击 复原到 -> 浏览所有版本，就可以查看每次保存的版本，选择相应版本即可回退至该版本。

保障文件安全

相信不少同学或多或少都遇到过文件损坏或丢失的情况：

• 自己误操作或软件崩溃导致文件丢失
• 突然停电，台式机中正在编辑的 Word 文件未保存
• 设备故障或 被盗，其中未备份的文件全部丢失
• 设备被 勒索病毒 攻击，必须付款才能打开
• 洪水、龙卷风或野兽来袭，存储文件的设备被损坏
• ......

大约一个月前，一位同学由于毕业论文开题报告保存的版本不对，给我发了下方截图中的消息。虽然我给她发了找回历史版本的 Office 官方文档，她自己也尝试了网上的各种「偏方」，但最终还是以失败告终，没能找回上次保存的开题报告，不得不「擦干眼泪，从头再来」。

虽然遇到这种情况很糟心，但在最后，我还是苦口婆心地向她强调版本控制的重要性。这也是我写这篇文章的原因之一，希望你能未雨绸缪、防患于未然，不再有我的同学这样的遭遇。

假设我的这位同学利用 Git 对开题报告的 Word 文件做好了版本控制，并将其存储在 GitHub 之类的远程服务器上，或者哪怕将 Word 文件保存在 OneDrive 之类的网盘中，也一定不会遭遇这种情况，不至于「从头再来」。

提高协作效率

如果没有版本控制，可能你就会面临下图中的情形：自己不断修改，形成 final.docx、final_1.docx、final_2.docx...... 与导师或协作者通过邮件、QQ、微信等工具相互发送 final_rev.docx、final_rev_1.docx、final_rev_2.docx...... 这简直就是扼杀创造力的行为！

什么是「纯文本式」版本控制？

Kieran Healy 教授 认为，办公室模式（The Office Model）倾向于使用 Microsoft Word 这种集合式的工具，对 Word 文件所做的修改记录存储在文件内部¹ ，以 Microsoft Word 中的「修订」为代表；而工程师模式（The Engineerings Model）中，纯文本文件是工作的中心，对纯文本文件所作的修改记录存储在文件外部，以 Git 为代表。

我在之前的文章中 介绍到，Git 主要针对纯文本文件进行版本控制，面对 .docx 或 .doc 这类二进制文件的表现并不如人意。虽然 Dropbox、坚果云之类的网盘可以进行简单的版本控制，但它们能做到的，仅仅是让用户知道某一个时刻保存的某一个版本，但不能知道文件内部的修改情况。当我们想要恢复之前的版本时，由于不知道文件内部到底是怎么修改的，因此到底应该恢复哪一个版本，就会感到困惑。

因此，「纯文本式」版本控制可以这样界定：

「纯文本式」版本控制是指在文件外部进行，并且能够记录文件内部修改情况的一种版本控制。

那么，如何对 Word 文件进行「纯文本式」版本控制呢？下面介绍两种方法：Git & Pandoc 和 Simul。

Git & Pandoc

Git 最初是被用来对软件源代码进行版本控制，对 .docx 这样的二进制文件的支持不太友好。但是借助 Pandoc，我们可以实现「曲线救国」，通过将 .docx 文件转换为 .md 文件，来实现 Git 对 .docx 进行「纯文本式」版本控制。

安装 Git 与 Pandoc

• 前往 Git 官网，选择对应的操作系统版本，下载安装 Git。
• 前往 Pandoc 官网，下载安装对应系统版本的 Pandoc。

如果你的操作系统是 macOS，推荐使用 Homebrew 来安装 Git 和 Pandoc：

brew install git pandoc

配置 Git

在用户文件夹下找到文件 .gitconfig，使用文本编辑器打开它，加入下面的内容，然后保存。

[diff "pandoc"]
  textconv=pandoc --to=markdown
  prompt = false
[alias]
  wdiff = diff --word-diff=color --unified=1

新建一个文件夹，这里命名为 git-word-demo。

# 进入 git-word-demo 文件夹
cd git-word-demo
​
# 创建 Git 仓库
git init

在 git-word-demo 目录下，新建一个文件 .gitattributes，写入下面的内容，然后保存。

*.docx diff=pandoc

编辑 Word 文件

git-word-demo 文件夹下，新建一个 Word 文件，这里命名为 example.docx，然后按照平常一样进行编辑，完成之后保存并提交，进入该目录，在终端中输入：

git wdiff example.docx

就可以像纯文本一样，看到增加或删除的内容。当然，使用 Git 的 GUI 客户端会更加直观，比如 GitHub Desktop，如下图所示，绿色表示增加的部分，红色表示减少的部分。

Simul

简介

Simul 是一个为 Microsoft Word 设计的版本控制和协作工具，使用 Simul 可以轻松地与他人进行协作，对 Word 文件进行「纯文本式」版本控制，Simul 的推特 称它是「Microsoft Word 中的 Git」。

Simul 集成了 Dropbox、OneDrive、Google Drive 等常见网盘，具有自动记录版本、版本比较、分支、合并、回退等功能。免费版本拥有 1 GB 存储空间、1 个文档创建者、1 个文件² 以及不限数量的协作者，如果需要更多的创建者、文件数量和使用 Simul 的 API，需要升级到 Individual 或更高级的套餐，详情可参考下表。

此外，对于学生、教师和非营利性组织，Simul 的所有套餐享有 50% 的优惠，可以前往 这里 填写邮箱和申请请求，之后就会收到 5 折兑换码。

使用

• 创建文件

Simul 支持三种创建 Word 文件的方式：

1. 上传文件
2. 创建空白文件
3. 从 SharePoint、OneDrive、Dropbox、Google Drive、Box 导入文件

• 编辑文件
  

创建或导入文件之后，点击右上角的「OPEN IN WORD」或「Open in Word Online」，就会打开桌面版或在线版 Word，在其中编辑保存之后，会自动存储到 Simul 中，默认生成 0.0.x 这样的版本号，也可以点击「Name this version」，手动为每个版本重命名。对于编辑过的部分，Simul 会在左侧用竖线进行标记，用蓝色表示增加的部分，红色表示减少的部分，并且可以在下方下载各个版本的 PDF 文件。

• 创建副本

点击右上角的更多按钮，再点击「Push to copy」就可以创建文件的副本。副本是基于当前版本的一个新文档，类似于 Git 中的分支（branch）。在需要的时候，可以在副本中编辑，然后合并到主文档，点击「MERGE」，就可以将副本合并到主文档中。

总结

Git & Pandoc 的组合与 Simul 各有优劣：

因此，我们建议，如果你有一定的 Git 使用经验，推荐使用 Git & Pandoc 来对 Word 文件进行「纯文本式」版本控制；如果你不熟悉 Git，可以考虑使用 Simul。当然，如果你认为，自己确确实实不需要这种「纯文本式」版本控制，甚至都不需要版本控制，请记住，一定要做好备份！