我们的Git工作流程

我们在开发过程中使用Git作为版本控制系统，并使用Gi​​tHub托管存储库。 我们的工作流程类似于git-flow ，但是由于我们的产品不使用版本控制，因此做了一些简化-游戏的唯一实际版本是正式版。 嗯，这并不完全准确，因为我们的内部服务器上也有游戏的快照，但是生产是错误报告可接受的唯一版本。

对我们而言，最重要的标准之一是拥有线性git历史记录，使开发人员可以轻松遍历/将其一分为二，以检查回归或错误源。 在非线性git历史记录的情况下，它可能是不平凡的：

• 虚幻引擎4：事件图
• 手机游戏测试-简介
• 通过蓝图使用UMG实现无状态UI
• Trivisk的强国Gems and Gold
• 混乱与此

我们的master分支的git历史如下：

除了允许简单的git-bisect ，这种结构还使我们能够遵循特定合并功能分支带来的更改，并在需要时将其还原。

为了进行开发，我们的git工作流程如下所示：

提取主副本：

  $ git checkout master 
  $ git fetch -p-标签 
  $ get merge --ff-only origin / master 

在其顶部创建一个分支：

  $ git checkout -b forum-filtering-218 

该名称包含问题跟踪器发出的问题编号。

处理代码并将更改提交到功能分支。 经过一段时间的黑客攻击后，有必要刷新分支以确保与其他开发人员的更改没有冲突：

  $ bin / git-刷新 

您可以找到 git-refresh 的来源 此处 ，但它有效地根据最新的master副本重新建立了当前分支。

当该功能准备好公开时，请再次刷新它并运行完整的测试套件：

  $ bin / git-刷新 
  $证明-l 

后者实际上是可选的，因为我们在创建拉取请求时拥有Jenkins钩子，该钩子将针对已发布的请求执行完整的测试套件。

在GitHub上发布功能分支：

  $ git push --set-upstream origin forum-filtering-218 

创建一个PR，并要求某人对其进行审查。 如果有注释，请修复代码并重新发布：

  $ bin / git-刷新 
  $ git push --force-with-lease起源 

当审阅者对PR满意时，将其与master合并：

  $ bin / git-与主合并 

该脚本类似于 git-refresh ，但是它另外创建了一个合并提交并推送到GitHub上。 这将自动关闭PR。 做完了！ 下一个生产更新将包含另一个功能。

每周一次，我们在master分支上选择一个点，其中包括最近完成的功能和修复，并将其标记为发行版，然后将release分支移至同一提交。 然后将此版本推送到测试它的开发服务器。 后来进入部署。

也许有更多的开发人员会需要更多的正式规则或一些其他工具，但目前我们对我们的方法感到非常满意：它使我们花费更少的时间来确定git并留给我们更多的时间来开发游戏的新功能。