发表日期：2019-02-18

还能这样玩？用 git 追踪 Word 文档的版本

—— 在写文章的时候，我们经常会遇到许多需要追踪文件版本的难题。现在你可以用流行的版本控制工具 Git 来为你服务啦！

---

在写文章的时候，我们经常会遇到许多需要追踪文件版本的难题。不论是随着你的编辑和修改不断变化的文件版本，还是和其他合作者一起编写文章，要想保留文档的修改痕迹往往要费时费力，效果还差强人意。

版本控制

对大部分人来说，微软的 Word 基本上是首选的编辑器，对于版本追踪来说，这事有点喜忧参半。好的一面是， Word 里确实带了一个追踪修订（Track Changes）功能，你可以用它追踪之前是谁改了这个文件，改了什么地方。糟的一面是，这个功能把所有的修订历史都存在同一个 Word 文档中，每次只能有一个人对文件做出修改。

这往往就意味着你不得不把文件用邮箱或者聊天工具传来传去，还得很小心别覆盖了错误的版本，这可真需要费上一番脑力的。

想要改变这种痛苦的局面，一般有两种选择：

1. 把 Word 文档放到某种协作工具，比如 SharePoint 或者 Office 365 里，或者干脆用 Dropbox 或者 Google 文档之类的网络版本管理服务来分享文章。
2. 换成其他带有成熟版本控制功能的写作软件。

如果这两种办法都不适合你，你其实还有第三种选择：用 Git 版本控制系统来管理你的文档。

Git 是什么

Git 是一个分散式的版本控制软件，它能帮助你追踪文件的更改情况，方便你快速地回退到任意一个版本。总的来说， Git 更多是用于追踪软件源代码的更改（毕竟它最初是由林纳斯·托瓦兹创作，目的是为更好地管理 Linux 内核代码的开发版本），但事实上，Git 可以被用在追踪任何你需要进行版本管理的文件上。

Git 是一个在你电脑上运行的开源软件，你无需付费即可在电脑上安装，并开始管理你的文档（或其他需要版本控制的复杂文件）。任何时候，只要你想要保存一个版本，你只需在 git 软件中进行一次提交（Commit）操作（命令行：git commit），并附上一个简短的描述（以及可选的标签） ，方便你日后浏览查找版本。

这个办法并不是很完美，因为 Git 最初是为管理源代码设计的，它处理文本文档的改变很高效，但并不能理解两个版本的 Word 文档之间到底有什么差异，无法直接看出修改部分。这也正是为啥有些人说，永远不要把非文本文件放在版本控制系统里——不过，说真的，你别听他们的。

Git 怎么玩

相反，我们可以用一些其他的工具，让 Git 可以解析 Word 文档并转换成普通的字符格式。这样一来，Git 就能像往常一样告诉你不同版本之间做出修改的部分所在。有好几个不同的工具能完成这样的转换，不过最近我发现多功能文档转换工具 Pandoc 也能解析 docx 格式的 Word 文档了，所以我打算用它。

在安装完 Pandoc 之后，你需要添加下面这两个设置文件，以便 Git 自动将 docx 文件转换成 markdown，并以字为单位（而不是行）对比版本之间的差异。

# 在你的 git 仓库根目录的 .gitattributes 中，添加：
*.docx diff=pandoc

# 在你的用户主目录里的 .gitconfig 中，添加：
[diff "pandoc"]
  textconv=pandoc --to=markdown
  prompt = false
[alias]
  wdiff = diff --word-diff=color --unified=1

于是，你就可以用 git wdiff 某个文件.docx 这样的命令来查看版本更改了（删除的部分标红色，增加的部分标绿色）。你还可以用 git log -p --word-diff=color 某个文件.docx 这样的命令来查看所有历史更改记录。

现在，你可以方便地追踪 Word 文档的版本，并看到所有的变化啦。也许你还需要能合并各种不同版本的 Word 文档，方便你和其他协作者同时并行处理一个文档。由于 Git 无法自动合并非文本文件，你需要先将 Word 文档转换成 git 可以理解的格式。

正如前面的例子那样，我们可以用 Pandoc 来解决这个问题——因为 MarkDown 也是文本格式的文件。当然，你也可以用 HTML 或 LaTeX 来处理，不过 markdown 标记的简单方便，能更好地适应版本控制的需求，毕竟 Git 可能无法完全兼容其他那些格式。

GitHub 协作

码农们都爱用 Git，有很重要的一个原因是，它是一个分布式的版本控制系统，而不是 Subversion 那种中心式的。这意味这你可以在任意本地计算机上追踪你的文件版本，也同时可以和其他用户同步你的版本。

于是，Github 出现了。Github 是一个非常流行的平台，它让这种代码库之间的同步变得更加方便快捷，还增加了许多很不错的功能。和你的合著者协作的办法之一，就是在 Github 上为你的文档建立一个仓库（公开或私有的都可以），把最主要的文件版本转换成 markdown 格式，存储在里面。

接下来，你并不需要在这个 markdown 版本上进行修改，你可以用 Github 把这个版本同步到本地，并用 Pandoc 转换成 Word 文档，方便你继续用 Word 来撰写文章。

我上周刚发现，Rakali是一个很棒的 Pandoc 工具，能自动帮你完成上面的转换工作。此外，Github 还带有许多方便的协作工具，供你和协作者使用，比如 GitHub Issues 工具，就能让你们提出备忘、需求，或是沟通留言、追踪进度等等。（译注：本博客的留言评论系统也是基于 GitHub Issues 的。）

进阶探索

上面这种工作流程虽然还是略显粗糙（例如，对 Word 修订追踪的支持不足），但在我看来，使用 Microsoft Word 和 git 进行协作是种有趣的尝试。当然，我们还可以进一步增强这个工作流，比如让它同时支持使用 LaTeX （或 Pandoc 支持的其他格式）进行编辑的作者进行协作。、

此外，使用 markdown 的一个不错的额外作用是，Github 会自动将文档在 Github 网站上变成一个网页的方式显示出来（而如果是 HTML 的话，你还得另外费上一番心力才能有同样的效果）。

（本文已投稿给「优达学城」。原作： Martin Fenner，编译：欧剃 转载请保留此信息）

编译来源： http://blog.martinfenner.org/2014/08/25/using-microsoft-word-with-git/

标签：Github