吸引非程序员(例如设计师)使用版本控制的简便方法?


13

使团队参与开发,Web开发或其他过程中使用版本控制的一些主要方法是什么?

我拒绝没有它的工作,这意味着参与该项目的任何人也必须使用它。这只是个好习惯。

像Tower这样的GUI有所帮助,但是它的概念要么激怒(“不是我的工作!”,有点怯,),要么胆怯,或者直接不使用它(改用FTP,绕开了诸如开发,部署之类的版本控制) )。

编辑:我应该澄清一点,我不仅仅是指图像/ PSD。


11
使其易于使用...

1
我发现,一旦您花了几天时间就对Git感到非常容易,并且对开发的发展方向达成了共识。对于其他人来说,它仍然是一个更大的障碍。
凯文

2
需要记住的一点是,版本控制和备份有时会融合在一起(尽管有很大的不同),并与具有二进制数据的设计者融合在一起。备份可能已经很普遍,因此需要了解他或她正在获得的知识。
亚伦·麦克弗

1
@Kevin:对于程序员来说,简单,显而易见和直观的东西不一定对其他人有任何意义,即使是聪明又有创造力的其他人也是如此。
David Thornley,

1
与设计师互动,然后将其私下与版本控制联系。:)

Answers:


11

我在一个由开发人员和设计师组成的团队中工作,我们都使用版本控制。对于设计师来说,这很糟糕。

文件共享/备份始终等于版本控制

当你说:

我拒绝没有它的工作,这意味着参与该项目的任何人也必须使用它。这只是个好习惯。

您需要意识到对二进制数据使用版本控制的陷阱:

  • 覆盖:如果两个设计者正在同一个文件上,则要提交的第二个设计者将覆盖第一个设计者的更改作为当前版本。防止这种情况的唯一方法是锁定或与谁在对哪个文件执行操作方面保持持续的通信,这两种方法都可能妨碍其团队的工作流程。
  • 合并:二进制数据中不存在工具辅助的合并。手动合并很麻烦,并且容易发生大量错误。
  • 存储库膨胀: VC系统仅存储文本文件更改的行。对于二进制数据,这是不可能的,因为整个文件看起来与VC系统不同。这意味着,虽然20个版本的10KB文本文件可能只占用20KB,但20个版本的1MB文件可能会占用近20MB。中等规模的设计团队可以轻松地对数十个二进制文件生成许多修订。您的IT部门可能很快会讨厌您的存储要求,甚至可能会增加VC服务器将拥有的内存/ CPU。

    您和其他开发人员也可能很快会讨厌结帐或更新需要花费多长时间,除非您建立了一个很好的存储库组织来避免使用二进制文件。

  • 降低的收益:您的设计人员很少,甚至永远不会返回到二进制文件的先前版本,因为1)没有简便的方法来检查过去版本的内容2)没有简便的方法来合并它,最重要的是,3)他们没有这样就行不通了-它们用于构建某些图形的替代版本,这些替代版本可能仍然对生产文件本身有用。

对于您的代码,您绝对应该使用VC,并且正确地要求它。

但是您需要检查一下这样的假设,即每个人必须使用它,以及它是否对设计人员来说甚至是一种好习惯(尽管有备份)。您应该将网站/应用程序所需的最终图形资产存储在VC中,但是对于生产文件,这可能不是正确的解决方案。


关于“存储库膨胀”:您可以尝试使用正确的文件格式来解决。以文档标记语言格式存储的文档和以图形标记语言格式(而不是等效的二进制格式)存储的图形会有很大帮助。当然,这是否可行取决于所涉项目以及相关人员的意愿和能力。;)
Baelnorn

5
有价值的VCS不会发生覆盖。发生的情况是您具有同一文件的两个版本。是的,存储库的HEAD将具有最后的保存;但是其他设计师的工作并不会像在共享硬盘上那样丢失。我认为这是一个重要的区别。
Berin Loritsch 2011年

2
@Berin:是的,但是现代VCS的好处之一是两个人可以同时处理同一件事,并且许多对帐工作是自动进行的。但是,对于没有有意义的合并过程的二进制文件,这是不可能的。此外,存储库的负责人是人们会认为“真实的”负责人。
jprete 2011年

1
由于源代码和设计文档的生命周期不同,请确保为其使用单独的存储库。我不同意存储库会吸引设计师。大多数时间都花在了思考和建模上,而不是对文档做很多小的改动。我们还规定禁止自动合并(对存储在存储库中的所有文件),因此必须对编辑进行强制性文件锁定。结合良好的团队沟通,可以避免您提到的许多弊端。
rsp

1
您完全错了,例如:覆盖 -这不是版本控制的问题,相反,它可以帮助您检测到它。VC系统仅存储文本文件更改的行。-git错误。
maaartinus 2011年

4

我拒绝没有它的工作,这意味着参与该项目的任何人也必须使用它。这只是个好习惯。

那是一种伟大的态度,就在那儿,“不是我的工作!” :-)

获得认可的最好方法是使用TortoiseGit或TortoiseSVN之类的东西将版本控制集成到Explorer(假设Windows)中。如果您不习惯版本控制范例,则需要花费一些时间才能看到真正的好处。龟纹至少使使用鼠标操作VCS变得容易。只需一个简单的“右键单击->签入”即可。

因此,我一直希望在每个关闭的文件中在TortoiseGit中实现透明的版本控制。如果您给某人一个分支进行工作,然后每个写入/关闭都会成为一个提交操作,那么作为开发人员,您有时可以合并他们的分支而不必担心整个存储库的一致性,并且他们可以继续进行。在不了解版本控制的情况下做他们要做的事情。

对于大量的审核文档,我也遇到同样的问题,我无法让人们进行版本控制,因此,同一文档中有50个版本,它们之间有很大的不同。


4

解决这个问题的方法是建立一个构建系统(如哈德森它使用)的版本控制系统检索生成源,使之成为项目的规则,只有文物,它们是通过构建系统交付将要测试团队和最终部署在客户现场。

非常清楚地说明,就项目流程而言,任何不是来自构建的东西都是开发人员专有的;只要不接受某人的工作,它就可能不存在。


2

说明优点:

  • 向他们展示如何通过允许所有人共享工作并访问中心位置来节省时间。
  • 向他们展示如何允许设计人员同时处理项目的不同部分并将其合并回去。
  • 向他们展示如何标记和构建较旧版本的应用程序以进行测试或故障排除。
  • 向他们展示如何在实验中弄乱设计,然后刷新项目,如果他们不愿意,则不保留更改。
  • 向他们展示如何看到随着时间的推移发生了什么。

1
-1这是关于聘请非程序员;该列表针对的是程序员。如果您修改答案,我一定会删除不赞成票...
Aaron McIver

1
我认为您错过了“面向非程序员”部分。您提到的所有任务都是程序员任务。
Erik Funkenbusch'2

抱歉,我只是看了问题,没有标题。我将编辑答案。
jzd 2011年

1已删除...
Aaron McIver

1

非程序员对版本控制的“不是我的工作”是理智的态度。

构建与Dropbox用于同步或Time Machine用于备份一样简单和不可见的版本控制系统。

它应该工作。没有结帐,没有提交。只需将文件放在项目文件夹中即可。


1

我一直在与新的网站女士一起使用tortoiseHG / mercurial,那里没有问题。没有签出将使其变得非常简单,并给实际上必须确保文件同步的人员带来了所有压力。它甚至看起来都不是“要做的另一件事”,而只是,“好,我要演示网站,所以我必须请Peter重新同步更改。” 没问题

我以前没有使用Mercury的经验,我们使用VSS,而且我绝对不希望对任何人进行网站源代码控制。我尝试过一次,不会怪任何人当时不想使用它。


0

我会说使用草龟*克隆,这很简单。或在IDE或其他任何版本中集成版本控制。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.