游戏开发的版本控制-我应该何时分支？

我最近开始在我的项目中使用版本控制（即使我一个人在工作）。我发现它提供了一种很好的方式来保留整个开发过程的历史记录（带有问题跟踪），并且使我能够一路保留项目的备份。

当我慢慢发现使用版本控制的功能和优点时，我陷入了分支的念头。我什么时候应该做？

是我每次去开发一个新功能，还是每隔一段时间才达到某个里程碑？

显然，当单独工作时，分支是没有用的，但是我宁愿现在养成良好的习惯并习惯它。

当我阅读Mike McShaffry撰写的《Game Coding Complete》一书时（这是一本很棒的书），当作者建议保留三个分支时，我完全迷失了方向，大致如下：

• 主要：定期进行更改的主要开发部门。
• 黄金：保留最后一个里程碑的黄金分支。
• 研究部：用于测试可能严重影响Main分支的东西（修改游戏引擎的重要组件等）的分支。

那应该是这样吗？与大型开发人员团队一起在游戏开发领域中如何真正发挥作用？

基本上：什么时候通常会在游戏开发中分支（并合并）？

分支在某种程度上取决于VCS对功能的支持（即：VCS是使它变得容易还是困难）。

但是至少，您需要为项目的每个独立支持的版本提供一个分支。也就是说，如果您具有“游戏2”和“游戏2 +扩展”，它们是从同一代码库中构建的独立产品，并且您需要能够对其进行补丁和发布更新，那么您希望每个都有它们存在于主代码库的各自分支中，因此可以将对核心代码库的修复独立地合并到每个产品中。（通常，这些分支是在每个产品发布时创建的，或者如果您不希望最初发布的版本中的代码库中有人从事某些工作，则可能在几天/几周之前创建）

如果使用的VCS使得分支的使用变得棘手或痛苦（SourceSafe，svn等），那么您可能最乐意为每个已发布的产品维护一个“ release”分支，并在“ trunk”中进行主要开发，当您需要发布针对这些发行版的修补程序时，可以将“ trunk”中的更改合并到“ release”分支中。

另一方面，如果您正在使用围绕分支和合并构建的较新的VCS系统之一（git，Bazaar，Mercurial等），那么在很短的时间内您可能会最快乐地进行开发的“功能”分支。例如，如果您正在研究AI寻路，则可以创建一个“寻路”分支并在其中实现代码。完成后，您可以将该分支合并回到开发的主干中，并（可选）删除您正在使用的分支。这种方法的好处是，它使您可以同时处理多个任务，而无需完成一个任务任务，然后再开始下一个。

在我当前的家庭项目（使用git）中，我现在有五个不同的功能分支处于活动状态，正在处理各种不同的功能。其中两种是做同一件事（用于概要分析）的替代方法，两种是实验性的游戏机制构想，一种是我的AI系统的重要重构，并且实际上被破坏了，导致代码无法正确编译现在。但是它已经提交到其功能分支中以供参考和备份，并且它的损坏并没有阻止我从事其他功能的开发。那些其他功能分支（以及主要开发主干）仍然可以正确编译并运行。

根据我在大型团队专业游戏开发中的经验，我们仍然主要还是停留在较旧（且受商业支持）的版本控制系统上。Perforce可能是最常用的，其次是Subversion。在我工作过的任何地方，我们都有一个“ trunk”分支，然后为每个可交付成果（里程碑/ demo / release / etc）提供一个单独的“ release”分支。有时，某人会为他们正在做出或测试的一些巨大变化做出一个个人分支，但这是极为罕见的，通常用于诸如“将游戏转换为使用该不同的物理库来运行”之类的事情，而这可能实际上并没有经过已发布的产品。

上面已经是一个很好的答案，但是要注意的一件事是何时要分支以及何时要标记。

大多数vc都允许您标记（有时称其为标签）。每次进行主要构建时（对于测试，beta测试或即将推出的功能），都应应用标签。如果您正在（并且应该）使用某种持续集成，则CI系统应标记成功的构建。基本上，任何时候您要做的事情都可能要回去（创建分支或检查您在该版本中做过的事情）制作标签/标签。它们通常成本低廉且易于添加。

我强烈建议另一件事是将您的资产和代码保留在同一版本系统中。如果您无法匹配（然后分支）资产，那么拥有一个代码分支（或标签）是完全没有用的。这是游戏公司喜欢Perforce的主要原因之一-与二进制代码文件存储代码一样，它也很高兴存储，并且（与git不同）它对于非技术类型而言也是可以理解的！

哦，每当您想将已编译的文件检入VCS停止位并考虑如何避免这样做时，就可以使用它。以我的经验，它几乎总是导致数据不匹配，缺少源（例如，压缩的DDS纹理被检入，但源png未被检入）以及混乱的局面。如果您有一个资产管道，通过将导出的文件缓存在某处（因此每个人都不会重新生成相同的文件集）而更好地解决了该问题，则可以通过一个过程在VCS中构建源资产并将导出的文件放入一个缓存（或共享驱动器，甚至是单独的VCS）。但是不要手工检查那些导出的文件-这会咬你（特别是如果你是团队成员）。

我喜欢那本书，并向有兴趣的所有人推荐。对于一个独立开发项目，除非您需要或想要创建单独的版本，否则根本不需要分支。例如适用于Android的操作系统和适用于PC的操作系统，等等。

如您所说，如果您想养成良好的习惯，我会赞同迈克的方法。这在我两个人的独立项目中很有意义，而且是我使用的方法。

您需要回去做更多工作的所有事情，都应该是可分支的（但不一定是分支的……）。

这样做的原因是简单的。您需要能够发布该代码的固定版本，而不是任何其他代码，因此在那时，您需要在分支上工作。

VCS是不同的。有些（例如git）很容易在以后的任何时间从任何提交分支，而其他一些（例如CVS）在以后使用时非常麻烦。

也许您想对stackoverflow提出一个问题，询问如何在所选的版本控制系统中发挥最佳作用？如果您还没有真正的悠久历史，则可能需要提出一个描述您的工作方式的问题，并为您推荐最佳版本控制系统？