【问题标题】:What are potential strategies for using Git with a large-ish game project?在大型游戏项目中使用 Git 的潜在策略是什么?
【发布时间】:2016-02-16 13:06:00
【问题描述】:

关于我的问题的一些背景知识,然后是一些问题:

我的团队将 SVN 用于许多游戏开发项目,并且在过去几年中为我们提供了良好的服务。但是,我们最近一直在探索是否应该迁移到 Git,原因如下:

  • 我们相信,Git 的分支功能将开启有益的编码工作流程和实践,这些工作流和实践在 SVN 中是困难的或不可能的(功能分支、合并前的代码审查、拉取请求)。
  • 我们团队的一些新成员从一家使用 Git 的游戏公司来到我们这里,他们感叹 SVN 中缺少 X 或 Y 功能。
  • SVN 相关工具的更新/维护似乎比以前少。简而言之,Git 和类似的东西很流行,而 SVN 正在变得不那么流行。

我们希望使用 Bitbucket,因为我们可以更轻松地与外部承包商协作,而不是在公司防火墙后面使用 SVN 存储库。

我们使用 git-svn 工具将我们的项目转换为 Git 存储库。 Git repo 最终变成了 6GB 的所有历史记录!不幸的是,这对于 Bitbucket 和 Github 来说太大了,它们都实施了 1-2GB 的限制。

这引起了一点“信仰危机”,即我们从 SVN 切换到 Git 是否做出了正确的决定。你可以在网上找到很多关于 Git 不适合游戏开发或者二进制文件令人头疼的意见。我们的计划是将源美术文件保存在 SVN 中,但游戏的任何“最终”美术资源都将存在于 SVN 中。此外,一组共享库将存在于链接到我们游戏存储库的单独 Git 存储库中(很可能使用子树或某些依赖管理系统)。

我正在寻找几个方面的答案/反馈:

  1. 对于 Git 存储库来说,6GB 是否过于笨重?人们是否能够有效地使用它,或者它可能没有响应或难以推送到遥控器?
  2. 将大型 Git 存储库拆分为几个较小的存储库以回避任何“大型存储库”问题是否合理?想一想,这似乎是一团糟,并且构建一个项目以适应版本控制限制并不适合我。克隆似乎也有问题 - 您需要单独克隆每个 repo,还是可以一次性完成?
  3. 其他人是否成功地将 Git 用于此类游戏开发项目,如果是,使用了哪些策略使工作流程尽可能简单?我们是否会花费更多时间来为我们的竞标争取版本控制,而不是实际开发游戏!?

那些不得不走这条路的人的任何反馈或见解都会很棒!

【问题讨论】:

  • 只要你还没有迁移,想想 Mercurial+LargeFiles - 更多利润,少很多头痛

标签: git svn version-control


【解决方案1】:

我没有将 Git 用于游戏开发,但用于具有大量视频资产的多媒体开发。

我们所做的与您的建议相似;我们将大型资产保存在一个单独的子模块中。需要一些培训(可能还有一些使常见案例变得更容易的包装脚本,我记不太清了)让每个人都习惯使用子模块,但一旦他们完成了,就相当顺利。

我们甚至允许在子模块中更改资产,一旦它变得太大,我们只需创建一个新的 repo 并将子模块切换到那个。这意味着您没有获得这两个部分之间的历史记录,但是由于它们是无关紧要的二进制文件,并且您始终可以使用git replace 将两个存储库的历史记录拼接在一起以获得完整的历史记录,如果您想要支付检查大型二进制 repo 的费用。

所以是的,我会说 Git 可以解决这个用例,只要您保持主存储库的大小合理且仅包含文本,并单独管理您的资产。无论是在 SVN 中并以某种方式导出,在您打破历史记录的 Git 子模块中,还是通过git-annex 之类的东西,您可能必须根据尝试几种方法并查看您认为哪种方法有效来弄清楚最好的。

【讨论】:

  • 自从写了上面的问题,我们的项目仍然托管在SVN上。但是,我们现在有另一个游戏项目,其中包含大量艺术资产,它成功地使用了 Git“LFS”(大文件支持)。因此,这似乎也是一个可行的解决方案。
猜你喜欢
  • 2013-04-09
  • 1970-01-01
  • 1970-01-01
  • 2020-06-01
  • 2012-07-27
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多