我们的Git工作流程

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

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

我们的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并留给我们更多的时间来开发游戏的新功能。


最初于 2018 年6月22日 发布在 blog.taustation.space 上。