
我们在开发过程中使用Git作为版本控制系统,并使用GitHub托管存储库。 我们的工作流程类似于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 上。