使用UDK进行游戏开发的版本控制系统？
我们是一个考虑使用虚幻开发套件制作游戏的团队，并且我们正在寻找版本控制解决方案。
我一直更喜欢 Git 和 Mercurial 等去中心化的 VCS，并将其用于我所有的个人项目。尽管我听说过使用这些系统进行游戏开发的问题，但它们不适合大型二进制文件。
Subversion 似乎是一个很好的解决方案，但是我过去根本没有使用过它，所以我真的不知道它提供了什么。
We're a team thinking of making a game using the Unreal Development Kit and we're looking around for version control solutions.
I have always preferred decentralized VCSs like Git and Mercurial, and used it for all my personal projects. Though I have heard of problems regarding game development using these systems, with them not being suitable for big binary files.
Subversion seems like a good solution, however I have not used it at all in the past, so I don't really know what it offers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以毫无问题地使用 Mercurial 或 Git。我不知道为什么 @TomTom 会以这样的方式另有说明，而没有提供任何有关原因的提示。
当然，您必须管理每个游戏开发中附带的各种二进制文件（电影、纹理、地图等）。但这两种软件都有处理它们的方法。
Mercurial
Mercurial 有各种扩展来处理大文件，尤其是二进制文件。
从 2.0 版开始，Mercurial 中包含了大文件扩展，您无需下载任何内容即可使用它别的。文件并不直接存储在存储库中，但 Mercurial 会跟踪每个变更集所需的文件版本，因此您可以在需要时使用正确的文件下载游戏的精确版本。
在2.0之前，主要使用两个扩展：
Git
比其他两个要复杂一些，我不太熟悉 Git 处理大文件的可能性，但我知道存在各种解决方案。这篇文章应该给出一些很好的指导：Managing large binary files with git
I'我们听说过很多关于 git-annex 的好消息。
SVN
我曾使用 SVN 处理大文件，但我并不认为它比 Mercurial（无扩展名）开箱即用地更好地管理它们。
如果您决定使用 Mercurial / Git 的扩展来管理大文件，Subversion 在功能方面远远落后。
结论
关于您关心的保持二进制文件版本与源同步的问题，bot Mercurial 和 Git 扩展可以很好地处理这个问题。
二进制文件的每个版本都存储在单独的集中目录中（Mercurial 术语中的
大型文件存储），并且当开发人员克隆存储库或更新到特定变更集时，仅所需文件可从该商店下载。您甚至可以将同一商店用于各种存储库！
将文件添加到存储或更新文件的过程对开发人员来说几乎是透明的，因此例如较长的学习曲线没有问题。
总而言之，我真的不明白为什么 Git 或 Mercurial 不能胜任这项任务，并且没有其他答案给出任何真正的原因。
在我看来，大型游戏公司坚持使用旧的工具，因为改变需要时间，而当你支付了某些东西后，你就可以使用它！有多少公司仍在使用 VSS 或 CVS 只是因为层次结构不会听到任何其他信息？上个月我们刚刚从我工作的地方迁移到 TFS（从 VSS）...
You can use Mercurial or Git without a problem. I don't know why @TomTom states otherwise in such a way without providing any hints about the reasons.
Sure you will have to manage the various binary files that comes with every game development (movies, texture, maps, etc). But both software have ways to handle them.
Mercurial
Mercurial has various extensions to deal with large files, especially binary ones.
Since version 2.0, the Large File extension is included in Mercurial and you can use it without downloading anything else. Files are not directly stored in the repository, but Mercurial tracks which version of the file is needed for each changeset, so you can download a precise version of your game with the right file when you need them.
Before 2.0, there was mainly two extension used :
Git
I'm not really familiar with Git possibilities to handle large files, but I know various solution exists. This post should give some good pointers : Managing large binary files with git
I've hear a lot of good about git-annex.
SVN
I've used SVN with large files, and I don't have the impression that it manages them better than Mercurial (without extensions) out of the box.
If you decide to use an extension to manage large files with Mercurial / Git, Subversion is way behind in term of functionnality.
Conclusion
About your concern to keep the binary files version in sync with the source, bot Mercurial and Git extensions handle this very well.
Each version of the binary files is stored in a separate centralized directory (the
largefile storein Mercurial terms) and when a dev clone the repository or update to a particular changeset, only the needed files are download from this store.You can even use the same store for various repository !
The process of adding a file to the store or updating it is nearly transparent to the dev, so no problem about a long learning curve for example.
To conclude, I really don't see why Git or Mercurial are not up to the task and no other answer gives any real reason.
In my opinion, big game companies sticks with older tools because change takes time and when you've paid for something, you use it ! How many companies out there are still using VSS or CVS just because the hierarchy won't hear anything about something else ? We just migrated to TFS (from VSS) last month where I'm working...
我会坚持使用 Git。存储大型二进制文件可能会带来一些损失，但作为一个团队一起工作，您会获得更多的好处。您将更新、更改、合并代码，而不仅仅是存储二进制文件，而 DVCS 可以更好地处理这个问题。
I'd stick with Git. What you may lose with the storage of large binary files, you'll more than gain in being able to work together as a team. You'll be updating, changing, merging your code a lot more than just storing binary files, and DVCSs handle this a lot better.
Hq(Mercurial) 2.0 对大文件的支持非常好。
以前是 LargefilesExtension，但从版本 2.0 开始，它随核心一起分发。
Hq(Mercurial) 2.0 support of big files is great.
Previously it was LargefilesExtension, but from the version 2.0 this is distributed with core.
完全无法使用。观点。
这里的技巧是，当您的存储库很重要时，您就不能拥有一个分布式存储库，并且这种重要性（数据量）可能与大多数人无关。
如果你从事游戏开发，你将拥有大量版本控制的资产，程序员对这些资产的兴趣为零。即使是大多数图形人员也不会关心。当您的存储库比典型的硬盘更大时，DCS 就会崩溃。并且根据您的图形水平，您可以轻松达到数千+GB的opf存储库。作为一名程序员，除了小测试图形之外，必须将其合并到我的本地存储库中，这一概念让我感到恼火，因为它让网络管理员发疯。
当你正确处理上面的动画/电影时，情况会变得更糟。每次更改和渲染都是另一个版本。繁荣。这对于在中央存储库中处理（我可以将光盘添加到中央服务器）来说已经足够糟糕了，当您将其分发给每个版本的每个团队成员时，它就完全无法使用了。
如果你能处理它的愚蠢的话，也许是这样。
我强烈推荐一个经过验证的解决方案 - perforce 几乎能够处理经过验证的问题。
TOTALLY unusable. Point.
The trick here is that you can not have one distributed repository the moment your repository is significant and this significance (data amount) is possibly irrelevant for most people.
If you do game development, you will have tons of version controlled assets that programmers have ZERO interest in. Even most graphics people wont care. DCS break apart the moment you can expect your repository to be larger than a typical hard disc. And depending how good you are graphics wise you can easily hit thousand+gb opf repository. The concept of having to merge that into my local repository as a programmer not dealing with the grpahics except small test graphics makes me kringe - as does it drive the network admin mad.
This gets even worse when you properly deal with animations / movies on top. Every change and render is another version. Boom. This is bad enough to handle in a central repository (where I can add discs to a central server), it is totally unusable the moment you distribute that to every team member IN EVERY VERSION.
Possibly, if you can deal with it#s stupidities.
I would strongly recommend a prooven solution here - perforce is pretty much able to deal with it prooven.
大型游戏工作室一般使用 http://www.perforce.com/ （说实话，我不知道为什么。）
SVN 也是一个相当不错的选择，但与 Git 和 Mercurial 相比，它有点过时了。
不管怎样，为什么要把大的二进制文件放在存储库上？您肯定会想为所有已编译的二进制文件等添加忽略行。始终确保仅包含源文件:-)
就我个人而言，我会坚持使用 Mercurial 或 Git。
Big game studios generally use http://www.perforce.com/ (to be honest, I have no idea why.)
SVN is a pretty good option as well, but it's a bit outdated compared to Git and Mercurial.
Anyway, why would you put large binary files on the repository? You'll definitely want to add ignore lines for all compiled binary files, etc. Always make sure to only include source files :-)
Personally I'd stick with Mercurial or Git.