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


26

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

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

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

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

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

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

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

基本上:什么时候通常会在游戏开发中分支(并合并)?

Answers:


32

分支在某种程度上取决于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”分支。有时,某人会为他们正在做出或测试的一些巨大变化做出一个个人分支,但这是极为罕见的,通常用于诸如“将游戏转换为使用该不同的物理库来运行”之类的事情,而这可能实际上并没有经过已发布的产品。


1
很棒的答案。在将其标记为可接受的答案之前,我将稍等一下,看看其他人是否也会根据自己的经验来带盐。
杰西·埃蒙德

8

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

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

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

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


+1讨论标记(我想谈谈,但不确定如何提要,但不会变得比我现在更加罗))。关于将已编译(或经其他方式处理的)文件检入VCS的要点也很不错,我已经在很多地方犯了这个错误,并且总是会令人心痛。
特雷弗·鲍威尔

1

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

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


1

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

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

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

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

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.