与其他的艺术家和创意人士合作时，我总是对他们的项目目录感到惊讶——坦率地说，还有点震惊。他们经常在目录中塞满了文件名相同，但后缀却用数字编号的文件，比如 -v1、-v2、-v3-FINAL、-v3-FINAL3、v3-FINAL3-real、-v3-FINAL5-please_will_it_ever_end 等等。
更令人惊讶的是，这些艺术家经常参与协作项目，在这些项目中，不止一个人可能会接触到同一个文件（或一组文件），而且往往是在很长一段时间内。我经常问这些艺术家：“你们有没有想过为你们的项目使用任何类型的版本控制？”
我总是得到这样的回答：“什么是版本控制？”
对艺术家来说，什么是版本控制？
我们生活在一个现代社会，拥有这些神奇的计算机设备，它们本应帮助我们提高效率。为什么我们这么多人仍然通过在文件名末尾添加数字和字母的递进来“版本化”我们的文件呢？
我们的软件开发界的朋友们已经多次以各种有趣的方式解决了这个问题。简而言之，版本控制最容易与视频游戏中的“保存状态”相提并论。当你对你的进度感到满意时，你就创建一个保存状态（在版本控制术语中称为提交）。从那里，你可以继续沿着你当前的路径前进，或者通过检出一个不同的路径（一个分支）来测试一个想法。无论你选择哪条路，你都可以随时回到任何之前的提交，并从那里重新开始。令人困惑的是，为什么这些工具在我们这些创作内容的人中没有得到更广泛的采用。为此，我将简要介绍一下我多年来一直使用 Mercurial 的方法。
Mercurial
任何已经了解版本控制软件 (VCS) 的人提出的第一个问题可能是：“你为什么要选择 Mercurial？” 的确，在开放和封闭的生态系统中，都有各种各样的其他工具。仅在开源方面，就有 Subversion、Fossil（它有一个内置的维基！）、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（等等）文件。
如果你不介意，请在评论中告诉我你对这类文章的看法。如果大家有兴趣，我当然可以在未来的“开放艺术”专栏中继续讨论这个问题。
祝你创作出很酷的东西！
16 条评论