从管理软件开发团队到成为游戏开发爱好者，我了解版本控制系统如何用于不同的工作以及原因。 我的开发人员同时在Git和SVN中工作，但在游戏开发方面，Git并非总是正确的答案。
对于这篇特别的文章，我想深入探讨为什么Subversion是一款出色的游戏开发版本控制系统。 这篇文章并不意味着在DVCS和非DVCS之间引发一场火焰之战，因为Git是当今大多数软件开发任务（并非全部）首选的VCS。
回顾分布式版本控制系统
Github在使Git成为土地法律方面做得非常出色。 通过围绕某种思考，构建和存储基于文本的源文件的方式来组织社区，它能够完成许多公司无法使用其他竞争技术的工作。 它在为所有新开发人员推广版本控制的Golden Hammer模型方面取得了巨大成功。 正如马斯洛所说，
“如果您仅有的工具是锤子，我想把所有东西都当作钉子来对待是很诱人的。”
这是围绕版本控制的基本问题。 很快就变成了一场宗教辩论，而不是着眼于实际的原因和有关最佳工作工具是什么的问题。
我一直在进行大量对话，结果是：“因此[回购技术]确实对在Node.Js中进行开发非常有用，所以对xyz的开发非常有用，对吧？”正在发生的事情是，开发人员是在大学里教过的，或者也许是一家公司文化，因为Git是一件事的最佳选择，所以它是所有事物的最佳选择。 毕竟，并非所有版本控制系统都是平等的。
对于游戏工作室而言，尽管许多工作室使用分布式VCS，但大多数工作室都不使用，并且有明确的原因基于其工作流程或游戏类型。 那么，为什么在开发游戏时使用Subversion？ 让我们在本论文中及其周围探讨一些有趣的主题。
合并总是有关的吗？
还记得过去的美好时光，Linus多年来一直安全地将tarball复制到kernel.org，而Git则是街头的新热点？ 如果Git参与其中并且可以轻松合并发行分支，他为什么要这样做？ 这是因为他的特定发布工作流程做得更好，更干净，没有分支。 没关系！ 最重要的是，仅仅因为工具可以很好地合并，并不一定意味着游戏工作室需要大量合并。 这是一个微妙的区别。 游戏的工作流程是不同的，它们具有各种风格。 Subversion实际上非常擅长合并，它既轻巧又快速，但这并不是重点。 考虑到Subversion 不擅长分支和合并的概念，请看一下svnvsgit.com上的示例数据， 其中包含常见的“太胖”注释。
这个故事的寓意是，当合并不是工作流中的头等公民时，基于合并能力选择工具将适得其反。 例如，Subversion是您要用来解决游戏开发中实际挑战（例如如何处理大文件）的锤子。
大文件管理
Git用户面临的最大挑战之一是大文件管理不善。 Git在1GB的存储空间之后就掉了，这就是为什么开发人员创建更多存储库并将代码拆分成存储库的原因。 游戏具有大量的二进制资产，范围从几千兆字节到几TB，因此这是游戏开发人员的主要障碍。 大文件问题的解决方案之一是Git LFS。 它旨在消除Git作为DVCS围绕二进制文件的体系结构限制。 Git LFS绝对是一个答案，但这是对Git所创建问题的答案。
我所看到的解决大文件问题的另一种方法是使用Git进行代码，使用Subversion进行资产。 虽然这是一种解决方案，但它真的是理想的解决方案吗？ 在某个时候，您必须问自己：是否必须为二进制资产实现单独的解决方案，也许您使用的是错误的版本控制系统？
另一个解决方案是将您的资产添加到Dropbox等文件存储平台。 我想重申一下本文的中心课程： 分别对资产进行版本控制，然后再编写代码是一个糟糕的主意。 使用像Dropbox这样的附加组件是一个解决方案，但是对于您令人惊叹的团队正在开发的出色游戏来说，这真的是一个很好的解决方案吗？
除了提出的解决方案外，我在许多Reddit论坛上都看到很多chat不休的话题，其中提到：“您不应该将游戏资产投入版本控制中。”这些评论确实凸显了所有开发人员都是平等创造的心态。 在很多方面，这确实使游戏开发与一般软件开发有所不同。 游戏资产和代码应合而为一。 代码与游戏中的数据紧密耦合，这不是错误。 当涉及到现实世界的游戏开发管道时，将它们拆分是一场灾难。
锁定图像
默认情况下，游戏将包含许多角色，模型和图像，在很多情况下，它们比源代码要多。 资产本质上是不可合并的。 Git，Subversion和许多其他回购技术都使用所谓的“复制-修改-合并”模型。 本质上，此模型假定所有内容都是可合并的。 不幸的是，对于无法合并的资产，该模型的价值为零。 那么，为什么除了可以同时支持两者的工具之外，还使用其他任何工具？
Git在新的Git LFS 2.2.0版本之外没有锁定。 Subversion锁定本机已经有很多年了，而且很快就会变得更好。 如果您需要处理角色而又不想让团队成员接触它，则可以轻松获取文件，对其进行锁定，对其进行处理，并且仅在完成后才提交并为他人解锁获得新版本。
这个过程代表了技术动画师，美术师，引擎程序员等在项目管道中构建游戏时所做工作流程的90％。 大型团队中有许多开发人员，他们一生都在C ++和Visual Studio中工作，但请记住，他们是大型团队的一部分。 团队的版本控制系统应涵盖所有情况，而不仅仅是少数情况，这是颠覆性统治的地方。 SVN内置了锁定功能，对于所有用户来说都是直观的，尤其是当与Tortoise SVN这样的本地应用程序耦合时。
对于游戏开发，永远不要使用没有内置本机锁定功能的VCS。您的创作者以后会感谢您！
“分布式”版本控制是最好的吗？
人类一直在犯错误，这是不可能防止的。 人们会做一些事情，例如将300MB的zip文件提交给版本控制（当然还有它旁边的zip文件中的所有文件），使每个人都可以在DCVS中永久下载该zip文件，因为它已经永远存在于历史中了。 它从未设计用于此用例。 Linux内核是成千上万个文本文件，由很多人管理，直到“直到最后”才相互之间没有任何连接。我将此称为私有或非协作开发。 它的根源来自此模型。
相反，Assembla的Subversion是一个非常协作的版本控制系统。 它是围绕整体存储库和中央协作的概念设计的。 例如，使用整体存储库的一些优点是：
- 更好的代码可见性
- 原子大规模重构
- 更好的团队间依赖性管理和协作
实际上，像Google这样拥有全球最大代码库的公司仍在使用整体模型。
DVCS用户将整个存储库本地存储在其计算机上是一项很棒的功能。 它有助于冗余和事件数据丢失时的备份。 同样，可以立即进行提交非常好，而且超级快速（因为它在您的计算机本地）。 当您要抓取某人的巨型ZIP图片图像纹理时，一次提交就减少几秒钟，就像新手跑步者将马拉松时间减少30秒一样-没关系。
使用DVCS时，期望您拥有正在使用的模块/组件的完整存储库。 如果您有一个100GB的存储库，则意味着您的硬盘驱动器上有一个100GB的结帐空间。 如果您使用的是Subversion，则只有当前签出。 如果您正在处理的当前版本或当前版本的子集（即仅签出您需要的文件夹）为2GB，那么您就可以使用该版本。 我需要什么吗？ 可能永远不会，但是如果我愿意，我可以抓住一切。
游戏开发=合作
游戏开发中有一些最多样化的团队。 您有艺术家，动画师，开发人员，设计师，制片人和导演。 技术人员和非技术人员都一样。 不要单独选择版本控制系统，这一点非常重要。 即使是Subversion，在我看来，这也是用于游戏开发的出色VCS，也只是一个仓库。 一个真正的团队需要一种方法来管理任务，沟通（例如，Slack），进行代码和资产审查，并且需要在一个平台上轻松地一起跟踪所有内容，以确保您的团队可以尽可能高效地工作，这将使您能够准时发布游戏。
不要只是获得一个Repo并计划在项目的稍后阶段进行协作。 同时做出决定。 您的团队稍后会感谢您。
DVCS什么时候有意义？
同样，我的团队同时使用Subversion和Git，但我仍然是DVCS的忠实拥护者。 我已经使用了Perforce和PlasticSCM。 所有这些都是好锤子。 这里有一些想法：
哪种类型的游戏会使DVCS成为不错的选择？
- 例如，当您有一款小型游戏而无意发展大型，小型移动应用程序时。
- 您的艺术品资产很少。 像素艺术，程序资产或文字冒险。
- 只是您在玩游戏-谁在乎历史发生了什么？ 祝好运！
- 您的整个团队了解Git之类的DVCS，这意味着不仅少数开发人员。 团队包括开发人员，艺术家，设计师。
什么时候是不好的选择？
- 如果您要制作3D形式的现代游戏，甚至是2D形式的复杂游戏，您都有很多资产（很有可能！）。
- 您有需要访问该项目的非技术用户，例如营销人员，内容艺术家或执行人员-信不信由你。
Subversion，[Perforce或PlasticSCM]快速，安全，可靠，仅适用于游戏开发。 并非所有的软件开发项目都是相同的-可以有不同的锤子。
这是与http://www.gamasutra.com/view/news/295558/Sponsored_What_to_think_about_when_choosing_a_VCS_for_game_development.php的交叉发布
