版本控制不仅仅适用于程序员

与其他的艺术家和创意人员合作时，我总是惊讶地——坦率地说，有点震惊地——看到他们的项目目录。他们经常在文件中使用相同名称开头，但后缀却带有编号，例如 -v1、-v2、-v3-FINAL、-v3-FINAL3、v3-FINAL3-real、-v3-FINAL5-please_will_it_ever_end 等等。

更令人惊讶的是，这些艺术家经常参与协作项目，在这些项目中，不止一个人可能会接触到同一个文件（或一组文件），而且往往持续很长时间。我经常问这些艺术家：“你们有没有考虑过为你们的项目使用任何类型的版本控制？”

我总是得到这样的回答：“什么是版本控制？”

艺术家使用版本控制是做什么的？

我们生活在现代，拥有这些神奇的电脑，它们本应帮助我们提高效率。为什么我们中还有这么多人仍然通过在文件名末尾添加一系列数字和字母来“版本控制”我们的文件呢？

软件开发领域的朋友们已经多次以各种有趣的方式解决了这个问题。简而言之，版本控制最容易与视频游戏中的“保存状态”相提并论。当您对自己的进度感到满意时，您就创建一个保存状态（在版本控制术语中称为提交）。从那里，您可以继续沿着当前的路径前进，或者通过检出一个不同的路径（一个分支）来测试一个想法。无论您选择哪种方式，您始终可以回到任何先前的提交并从那里重新开始。令人困惑的是，为什么这些工具在创作内容的人们中还没有得到更广泛的应用。为此，我将简要介绍一下我多年来一直使用 Mercurial 的方法。

Mercurial

对于已经了解版本控制软件（VCS）的人来说，第一个问题可能是：“你为什么要选择 Mercurial ？” 确实，在开源和闭源生态系统中都有各种各样的其他工具。仅在开源方面，就有 Subversion、Fossil（它有一个内置的 wiki！）、Bazaar，以及——可以说是最流行的 VCS——Git。在专有方面，有 Perforce 和 Alienbrain 等产品。甚至 Dropbox 也允许您回滚到文件的早期保存版本。那么，为什么要选择 Mercurial 呢？

这是一个个人决定，所以我确信其他人可能会选择不同的工具。但是，这里简要概述一下我的理由：

• 它不需要集中式服务器。 Mercurial 是一种分布式版本控制系统（DVCS）。 除此之外，这意味着所有版本控制都可以在您自己的计算机本地完成。 因此，与 Subversion 甚至 Dropbox 不同，您不必依赖单独的服务器来存储项目文件的版本历史记录。
• 它是跨平台的。 可悲的是，并非所有与我合作的其他艺术家和创意人员都在开源操作系统上。 虽然大多数其他 DVCS 程序都有带有命令行界面的端口，但 Mercurial 在 TortoiseHg 中有一个非常成熟的图形前端。 我建议人们从命令行对 Mercurial 有很好的了解，但许多艺术家确实欣赏一个好的点击式界面……而且 TortoiseHg 中的历史记录视图非常令人愉快。
• 它具有简单、易于理解的工作流程。 Mercurial 没有 Git 所获得的普及度或近乎普遍的存在。 但是，至少对我而言，工作流程更加直接。 对于大多数创意人员所做的那种工作而言，诸如暂存区和历史记录可变性之类的功能往往不值得额外的程序开销。 记住要使用有意义的提交信息进行显式提交（别担心，我们很快就会介绍这一点）已经比许多创意人员愿意付出的努力更多了。 暂存文件，或者在 Fossil 的情况下，确保存储库数据库已打开，这超出了我们想要（或需要）考虑的范围。

还有一些传闻证据表明，Mercurial 可能更有效地处理二进制文件（例如图像和其他媒体文件，这是大多数创意作品的主要内容）。 此外，我读过的关于分布式版本控制的最佳入门读物之一（Joel Spolky 的 Hg Init）是以 Mercurial 为重点编写的。 诚然，几乎所有的版本控制系统并非都旨在支持创意制作中常见的文件类型（大型二进制文件），并且有一些专门针对这种情况的系统（称为数字资产管理软件或 DAM）。 但是，它们往往过于特定于特定的媒介或工作流程风格，不符合我的口味。

这就是我个人选择 Mercurial 的原因。 也就是说，在我将在此处描述的大多数其他系统中，都有一个类似的过程。 因此，如果您更喜欢使用 Git 或 Fossil，我认为这很棒。 至少您在使用某些东西。 这使您比大多数其他创意人员领先一步。

开始之前

我将 Mercurial 和 TortoiseHg 的安装过程留给他们的文档以及您对自身操作系统的理解。 但是，在创建您的第一个项目仓库之前，您需要执行一个强制性的配置步骤。 您需要标识自己的身份。 请记住，Mercurial 是一个分布式版本控制系统，旨在允许多人团队在同一个项目上进行协作。 当您进行协作时，您需要一定程度的责任制。 您需要知道是谁做了什么更改。 这样，您可以单独联系该人以获得有关更改的更多说明。

设置您的身份非常容易。 从终端窗口，您可以键入 hg config -e。 这将打开一个文本编辑器，其中包含您的 Mercurial 配置文件（通常是您主目录中的 .hgrc 或 hgrc。 在该文本文件中，输入以下内容（或编辑它，如果它已在那里）：

[ui]
username = Your Name 

保存并关闭文件，您就设置好了。 当然，有一种从 TortoiseHg 执行此操作的图形方式（文件→设置→全局设置→提交），但正如我所说，我建议您了解如何从命令行执行此操作。 这使您在从图形方面工作时更有效率。

Mercurial 入门

好的，说了这么多，如何开始进行版本控制业务呢？ 好吧，第一步是创建您的仓库。 仓库（简称“repo”）是您项目的所有相关文件都保存（和版本控制）的地方。 虽然可以有一个分解为多个子仓库的单个主仓库，但推荐的做法是为您处理的每个项目设置一个单独的仓库。 我对此唯一的例外是针对小型、单文件项目。 例如，我为我的所有 Opensource.com 文章保留一个仓库，因为每篇文章只有一个文件。

要启动您的仓库（或初始化它），该过程很像启动任何大型项目。 首先为项目创建一个目录。 然后您进入该目录并初始化您的仓库。 从命令行来看，步骤如下：

$ mkdir myproject
$ cd myproject
$ hg init

最后一条命令 hg init 是 Mercurial 命令（所有 Mercurial 命令都以 hg 开头；Hg 是汞的化学符号），用于初始化您的仓库。 如果您从 TortoiseHg 执行此操作，请转到文件→新建仓库，并使用弹出对话框选择项目目录的路径。 然后它会为您运行 hg init 命令。

当然，如果您实际上没有任何项目文件在其中，仅仅拥有仓库对您没有太大好处。 不幸的是（但有充分的理由），这不像在仓库的目录中复制或创建文件那么简单。 它不是自动的。 您希望 Mercurial 跟踪（即，保留版本）的任何文件都需要显式添加到仓库中。 从命令行（假设您仍在项目目录中）：

$ hg add totally_sweet_painting.ora

这让 Mercurial 知道您希望它跟踪对您的文件的更改——在本例中是 totally_sweet_painting.ora。 在 TortoiseHg 中，您可以从左下方面板执行此操作。 您应该看到您的文件在那里列出，其左侧有一个复选框和一个问号。 您可以右键单击文件名，然后从出现的上下文菜单中选择添加。

Mercurial 现在知道要跟踪您文件上的更改，但它还不知道实际上已进行了任何更改。 您需要显式提交您的更改和更新到仓库。 并且在提交时，您需要包含一个注释或消息，描述您所做的更改。 这似乎是不必要的麻烦，但请相信我，当您几个月后（或者，就我而言，第二天）回到您的项目时，拥有有关您的更改的额外信息真的很有用，这样您就可以更好地了解您的方向。 用一句老生常谈的话来说，那些不了解自己版本历史的人注定要在他们的项目中重蹈覆辙。

在最简单的提交类型中，您将关于您的更改的消息全部包含在同一行中，如下所示：

$ hg commit -m "Added my totally sweet painting to the repo."

要从 TortoiseHg 中执行相同的操作，请使用界面最右侧的“提交”按钮。 当您单击该按钮时，会出现一个对话框。 该对话框显示提交（或变更集）中的更改，并为您提供一个文本区域，用于输入您的提交消息。

就这样。 从这里开始，您继续处理您非常棒的绘画。 当您继续工作时，定期向您的仓库提交，记录您通过修改文件或添加新文件所做的更改。 您无需在每次保存文件时都执行此操作（我们中的一些人已将 Ctrl+S 内置到我们的工作风格中，以至于点击它几乎就像肌肉抽搐一样）。 但是，当您进行重大更改或在您即将离开工作一段时间之前进行提交是一个好主意。 同样，使用视频游戏中的“保存状态”类比作为您何时适合提交的经验法则。

在您工作时，您可以随时询问 Mercurial 它认为自上次提交以来哪些文件已更改。 您只需要发出以下命令：

$ hg status

然后，Mercurial 将列出哪些文件已更改、哪些文件已添加以及哪些文件根本未被跟踪。 在 TortoiseHg 中，这些更改显示在左侧的文件列表窗格中（您可能需要单击“刷新”按钮以获取当前视图）。

对我来说，我通常同时打开一个终端窗口和 TortoiseHg。 我从终端输入所有 Mercurial 命令，并且可以从 TortoiseHg 获取快速（且有吸引力的）提交历史日志。 从技术上讲，我想我可以从 TortoiseHg 的集成控制台窗格（视图→显示控制台）完成所有命令行工作，但我通常无论如何都会打开一个终端，所以对我来说这没什么大不了的。

了解应该版本控制什么

一旦您弄清楚了版本控制的工作原理，您就会很想在项目中的所有内容上使用它。 虽然这样做有一定的价值，但这不一定是管理项目仓库最有效的方式。 例如，如果您倾向于收集参考文件（视频、照片、情绪板插图等），这些文件往往变化不大，并且实际上不是项目本身的一部分，因此它们实际上不需要进行版本控制。

这是在输入方面。 在输出方面，我倾向于使用类似于软件开发人员使用版本控制的方法。 也就是说，我只版本控制我的“源”文件，而不是从该源派生的输出文件。 例如，如果我在 Inkscape 中进行设计，我将把我的 SVG 文件包含在仓库中。 但是，如果我需要交付导出的 PNG 或 PDF 或 EPS 文件作为完成的作品，我不会使用 Mercurial 对这些文件进行版本控制。 我总是可以（相对容易地）从源 SVG 重新导出，因此即使这些导出文件丢失也没关系。 因此，我不需要通过跟踪它们来使我的仓库变得混乱。

在像 3D 动画这样更大的项目上，这可能会有点模糊，在这些项目中，重新生成动画帧是一个计算密集且耗时的过程，如果您不必这样做，您就不想重复它。 但是，对于这些类型的项目，我仍然更喜欢将输出文件保留在我的主仓库之外。 如果对这些文件进行版本控制确实至关重要，我可能会选择创建一个辅助仓库或一个子仓库，专门用于保存该输出，但这有点更高级的主题了。

当然，关于版本控制主题，除了我在这篇小文章中给出的内容之外，还有很多内容，例如将仓库克隆到其他计算机以进行协作或远程工作，创建分支以安全地试验想法和变体，以及将提交标记为重要的里程碑。 但是，这应该足以让您开始走上正确的版本控制之路，并使项目目录永远摆脱那些可憎的 v2、v3-FINAL、v13-FINAL8（等等）文件。

如果您不介意，请在评论中告诉我您对这类文章的看法。 如果有人感兴趣，我当然可以在未来的“开放艺术”专栏中继续讨论这个问题。

祝您创作出很酷的东西！