UDK游戏开发的版本控制系统？

Question

我们是一个考虑使用Unreal Development Kit制作游戏的团队，并正在寻找版本控制解决方案。

我一直喜欢像Git和Mercurial这样的分散式版本控制系统，并且在我所有的个人项目中都使用了它们。尽管我听说过关于使用这些系统进行游戏开发的问题，因为它们不适用于大型二进制文件。 Subversion似乎是一个很好的解决方案，但我以前从未使用过它，所以我真的不知道它提供了什么。

- user1039218

---

这个程序相关的内容翻译成中文：这是否应该转到游戏开发板块以获得更具代表性的回答？ - prusswan

我建议将大型二进制文件与源代码分开存放。 - Michael Krelin - hacker

@Michael 起初听起来是个不错的解决方案。但后来我意识到二进制文件和源代码之间有很多连接。这可能会使它们更难以相互同步。 - user1039218

我认为大部分时间（比如提交的百分比）这不是一个问题。我也认为一旦所有特定于您的开发人员和开发流程的技巧得到适当应用，git子模块工作得非常好。总之，这是学习曲线的常规事情。 - Michael Krelin - hacker

Answer 1

你可以毫无问题地使用Mercurial或Git。我不知道@TomTom为什么要这样说，却没有给出任何关于原因的提示。

当然，你必须处理与每个游戏开发相关的各种二进制文件（影片、纹理、地图等），但是这两个软件都有处理它们的方法。

Mercurial

Mercurial有各种扩展来处理大型文件，特别是二进制文件。

自2.0版以来，Large File extension已包含在Mercurial中，你可以在不下载其他任何东西的情况下使用它。文件不会直接存储在版本库中，但Mercurial会跟踪每个changeset所需的文件版本，因此，当你需要它们时，可以下载游戏的正确版本和相应的文件。

在2.0版本之前，主要使用了两个扩展：

1. Bfiles extension，作为2.0新扩展的基础。 2. Bigfile extension，在我看来比另外两个复杂一些。

Git

我不太熟悉Git处理大型文件的可能性，但我知道有各种解决方案存在。这篇文章应该会提供一些好的指针：Managing large binary files with git 我听到过关于git-annex的很多好消息。

SVN

我使用过带有大型文件的SVN，我没有觉得它比Mercurial（不带扩展）在开箱即用方面表现更好。

如果你决定使用扩展来管理Mercurial / Git的大型文件，则Subversion在功能上远远落后。

结论

关于你担心保持二进制文件版本与源代码同步的问题，Mercurial和Git扩展都处理得非常好。

每个二进制文件的版本存储在单独的集中目录中（Mercurial术语中的largefile store），当开发人员克隆版本库或更新到特定的changeset时，只会从此存储库中下载必需的文件。

你甚至可以将同一个存储库用于各种版本库！

向存储库添加文件或更新文件的过程对开发人员几乎是透明的，因此不会出现长时间的学习曲线等问题。

总之，我真的不明白为什么Git或Mercurial不能胜任这项任务，其他回答也没有给出任何真正的理由。

在我看来，大型游戏公司坚持使用旧工具是因为改变需要时间，而且当你已经支付了某些东西时，你会使用它！有多少公司仍在使用VSS或CVS，只是因为管理层不愿意尝试其他工具呢？我们上个月才从VSS迁移到TFS（我所在的公司）。

- krtek

---

使用Mercurial或Git，我会为您的艺术资源创建一个单独的存储库，并将其包含为子存储库。或者将它们完全分开，让构建过程将它们捆绑成二进制文件，在编译和打包游戏时动态下载。然后，您可能甚至不需要使用大文件扩展名。 - Laurens Holst

Answer 2

我会选择Git。虽然在存储大型二进制文件方面可能会有所损失，但你将获得更多的团队协作能力。你将频繁更新、更改、合并代码，而不仅仅是存储二进制文件，而分布式版本控制系统可以更好地处理这些任务。

- Abizern

---

我听说跟踪这么大的文件会有内存问题，那对我们来说不是一个很大的问题吗？ - user1039218

Answer 3

Hq(Mercurial) 2.0对大文件的支持非常好。

以前是LargefilesExtension，但从2.0版本开始，它已经与核心一起分发了。

- Dima Pasko

Answer 4

我一直更喜欢像Git和Mercurial这样的去中心化版本控制系统，

完全不能使用。点。

关键在于，当您的存储库变得重要且此重要性（数据量）对大多数人可能无关紧要时，您无法拥有一个分布式存储库。

如果您进行游戏开发，您将拥有大量版本控制的资产，程序员对此毫无兴趣。即使是大多数图形人员也不会在意。DCS在您可以预期您的存储库大于典型硬盘时就会崩溃。根据您的图形处理能力如何，您很容易达到千兆字节级别的存储库。作为一个程序员，必须将其合并到我的本地存储库中的概念（除了小型测试图形外，不涉及图形）让我感到不适-同样也让网络管理员发疯。

当您在顶部正确处理动画/电影时，情况会变得更糟。每个更改和渲染都是另一个版本。砰。这在中央存储库中处理起来已经够糟糕了（我可以向中央服务器添加光盘），但是在每个团队成员的每个版本中分发它时完全无法使用。

Subversion似乎是一个不错的解决方案，

如果您能处理它的愚蠢。

我强烈建议在这里使用经过验证的解决方案 - Perforce几乎能够处理它。

- TomTom

---

你可以为每个独立的部分拥有多个单独的Git存储库，没有任何阻止。 - poke

当然，Perforce看起来不错。唯一的问题是它的成本。我不会真的说这个游戏是非常严肃的事情，所以我们不会在上面花费大量的金钱。那么我们唯一的选择就是SVN，对吧？ - user1039218

嗯，不是的。应该有其他选择。很多东西取决于你的平台等因素。个人而言，我会去注册MS BizSpark，用100美元获得3年所需的一切 ;) 但是...是的，SVN看起来相当不错。即使如此，您可能仍会在服务器上遇到大小问题。 - TomTom

@TomTom，为什么Git和/或Mercurial是“完全无法使用的。一点问题都没有。”它们有很多方法可以处理大文件而不会出现故障，除了这个特定的问题，我真的看不出有什么问题。它们都提供扩展来管理大型二进制文件，并让开发人员下载它们或不下载。 - krtek

@Gustav 我不会说Perforce的唯一问题是价格。我还会说它过于复杂，经常会妨碍工作。话虽如此，对于大型代码库，它确实非常快速。个人而言，我更倾向于Mercurial + LargeFiles，但我知道这是最近才加入的功能。 - Paul S

Answer 5

大型游戏工作室通常使用http://www.perforce.com/（说实话，我不知道为什么）。

SVN也是一个相当不错的选择，但与Git和Mercurial相比有点过时。

无论如何，你为什么要将大型二进制文件放在代码库中呢？你肯定会想为所有已编译的二进制文件添加忽略行等。一定要确保只包含源文件 :-)

个人而言，我会坚持使用Mercurial或Git。

- Tom van der Woerdt

---

问题是，UDK游戏中的大多数内容都是二进制的，例如所有地图数据。 - user1039218

如果您将二进制文件从存储库中删除，您将失去检出完整项目的能力。如果您在版本之间更改了某些图形，然后检出以前的版本，除非它们在同一个存储库中，否则您将失去所有图形和代码之间的联系。 - Abizern

@Abizern：我只是指编译好的二进制文件。源文件当然应该始终保存在代码库中，其中还包括纹理文件。 - Tom van der Woerdt

再次强调，源数据必须始终在存储库中，否则您将丢失数据。您只需不包括编译版本，例如UDK创建的大型安装程序即可。 - Tom van der Woerdt

Mercurial和Git都有扩展来管理大型二进制文件，并使它们与源代码保持同步。然而，为了避免增长问题，这些文件并不直接存储在仓库中。请参阅我的答案以获取更多详细信息。 - krtek