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

还没有读者喜欢这个。
Open art versioning

Opensource.com

与其他的艺术家和创意人士一起工作时,我总是对他们的项目目录感到惊讶,坦率地说,还有点震惊。他们目录中经常充斥着以相同名称开头,但后缀编号的文件,例如 -v1-v2-v3-FINAL-v3-FINAL3v3-FINAL3-real-v3-FINAL5-please_will_it_ever_end 等等。

更令人惊讶的是,这些艺术家通常还参与协作项目,其中多人可能会接触到同一个文件(或一组文件),而且往往持续很长时间。我经常问这些艺术家:“你们有没有考虑过为你们的项目使用任何类型的版本控制?”

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

艺术家的版本控制是什么?

我们生活在一个现代化的时代,拥有这些神奇的计算机,它们应该帮助我们提高效率。为什么我们中还有这么多人仍然通过在文件名末尾添加数字和字母的 progression 来“版本化”我们的文件呢?

软件开发领域的朋友们已经多次以各种有趣的方式解决了这个问题。简而言之,版本控制最容易与视频游戏中的“保存状态”相比较。当您对自己的进度感到满意时,您就可以创建一个保存状态(在版本控制术语中称为提交)。从那里,您可以继续沿着当前路径前进,或者通过检出一个不同的路径(一个分支)来测试一个想法。无论您选择哪种方式,您都可以随时回到任何以前的提交并从那里重新开始。令人困惑的是,为什么这些工具在创作内容的人们中没有得到更广泛的采用。为此,我将简要介绍一下我多年来一直使用 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 配置文件(通常是您主目录中的 .hgrchgrc。在该文本文件中,输入以下内容(如果已存在,则编辑它)

[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 动画这样更大的项目中,这可能会有点模糊,在这些项目中,重新生成动画帧是一个计算密集型且耗时的过程,如果您不必重复它,您就不想重复它。但是,对于这些类型的项目,我仍然更喜欢将输出保留在我的主存储库之外。如果版本化这些文件确实至关重要,我可能会选择创建一个辅助存储库或一个子存储库,专门用于保存该输出,但这有点高级主题了。

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

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

祝您创作出精彩的作品!

User profile image.
Jason van Gumster 主要创作虚构内容。他写作、制作动画,偶尔也进行教学,所有这些都使用开源工具。他经营一家小型独立动画工作室,撰写了《Blender For Dummies》和《GIMP Bible》,并继续在他[有时]每周一次的播客“开源创意播客”中滔滔不绝地讲述他的经历。在 @monsterjavaguns 上进行冒险(和谎言)。

16 条评论

很棒的文章!我多年来一直想设置一些东西,但从未真正付诸行动。我现在再试一次。

我也做同样的事情,但使用 Subversion 和 Tortoise。我将 SVN 用于 Blender 文件和 Python/C

不错!Subversion 仍然是创意项目(特别是协作项目)的不错选择。这是我开始使用的 VCS,并且使用了多年。发生在我身上的事情是我变得懒惰,不想仅仅为了 Subversion 而设置服务器。 :)

回复 作者 antonioya (未验证)

只是想说一下,我在我的个人项目中使用 subversion 在同一台机器上作为“服务器”,没有任何问题。至少在 Windows 上和使用 Tortoise,这是相当轻松的。可能会考虑 Hg。

回复 作者 Jason van Gumster

感谢您指出这一点,Tony。您绝对是对的。我可能没有充分解释我有多么懒惰(一个“hg init”命令 vs. 仅仅 2-3 个简单的步骤来创建一个本地 Subversion 存储库)。

回复 作者 Tony (未验证)

这完全公平,可能也是我很快会尝试 Mercurial 的原因。通常与其说是节省时间,不如说是降低门槛/消除障碍。额外的步骤带来的精神负担往往会累积,尤其是在艺术方面,人们可能会相当频繁地启动新的存储库。

我坚持使用 SVN 是因为据我所知,它比 GIT 更好地处理二进制文件——包括执行增量的能力。但我也听说过那些增量实际上并没有节省多少。我当然愿意四处看看。

当我在考虑这个问题时,可能是提醒人们版本控制本身可能不应该是您的备份解决方案的好时机。 :)

回复 作者 Jason van Gumster

我记得前段时间有一篇文章是关于将版本控制用于文档的。我知道在我的商店里正在使用它。

这是我使用搜索引擎找到的。

http://www.makeuseof.com/tag/not-just-for-coders-top-version-control-sy…

我并不惊讶它可以用于相互协作的艺术家。我认为这是一个好主意,因为它使一切井井有条,并提供在出现严重错误时回溯的能力。

版本控制不是唯一可以用于其他事物的技术。例如,我使用 Mantis (www.mantisbt.org) 跟踪我的家务和项目。它比 Hi 和 Lois 的家务罐更好。 :)

在家里,我有一个 cvs 存储库用于个人作品。我使用 cvs 的原因只是熟悉它。

哇,CVS?真的吗?我*没有*想到会看到它。但您是对的。它很熟悉并且仍然有效。我当然可以看到它在写作中很有用。我喜欢您使用 Mantis 的方式……我使用 Redmine 做类似的事情。

另外,感谢您分享该链接……对于那些专注于写作的人来说,这是一个非常好的选择概述。

回复 作者 Papo Anaya

我今天的提示
使用秘密分支,并使用 graft 将 cherry picket 版本插入到主分支中

哦,我多么喜欢 graft。当我想要从包含多个文件的提交中 graft 单个文件的更改时,我才遇到问题。不过,这很容易解决。

感谢分享!

回复 作者 SaltatorMortis (未验证)

我更喜欢 GIT。以前用过 SVN,但 GIT 领先几个光年。

Jason,好文章。我的职业生涯始于 80 年代中期创立和运营一家版本控制公司,成为一名软件企业家。我记得那时试图提出这个论点,人们的眼睛只是变得茫然。(当然,我也记得一位工程经理解释说他们不需要我们的产品,因为“他们是一家只有 15 名程序员的小店。”时代变了。)

Creative Commons License本作品根据 Creative Commons Attribution-Share Alike 4.0 International License 许可。
© . All rights reserved.