作者：刘宇

背景

Git 是现在最为流行的源代码版本控制软件，更好的解决了多个协作问题。

协作必须有一个规范的工作流程，才能让大家有效地合作。工作流程在英语中叫：Workflow，或者 Flow，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。

而现在主要流行的有：Git-flow 、Github-flow 、Gitlab-flow。

每个流程都各有千秋，今天我们在这里不讨论它们，而是谈谈我们团队在使用 Gitlab做敏捷开发时，做出的一些小优化与规范，算是对自己的一些总结。

实践探索之路

在开发的过程当中，有着各种各样的需求与想法。各个公司及团队都在提倡敏捷，而如何将敏捷落地，找到适合自己的方法，却没有一个定论。

开发的流程并不是一成不变的，而是根据不断的探索、尝试，找到属于自己团队的Flow。

在这个过程当中，有几个功能是必须遵循的。由于我们一直在使用 Gitlab，而 Gitlab在版本不断的迭代当中，也在逐步的往这一方向靠拢，因此针对这些流程的使用做一个归纳。

1. 缺陷跟踪：[issue tracking]
2. 代码审查：Pull Request
3. 持续集成：[Continuous integration]

• 缺陷跟踪，是非常重要的一个环节，我们可以利用issues号相互链接，同时可以通过缺陷跟踪来制定项目发布计划，周任务等。

• 代码审查，我们将这个做到 PR 里来，不再引入外部工具，原因是 PR 够用，并且目前已经很好用了，有问题可以 commit，或直接在代码级别 commit。

• 持续集成，在使用 Gitlab 时，7.X 版本时还是单独存在，8.0 后就直接集成了，非常好用。配合 Go 的客户端 Gitlab-runner。可以实现在版本发布时，直接推到服务器部署。

简陋的管理

最简陋的第一个版本，由于人员少，我们只是利用几个分支，开发不同的功能，然后合并上线。时间长了便发现，有特别多的分支以及 issue 没有closes，commit 与分支命名也没有一个比较好的规范。

质的飞跃

经过一次大的梳理，我们对流程进行了大量的改进。
在新的约定开发流程下，开发者小星星的新功能开发如下：

1.  从基准分支 `develop` 分支切出一个特性分支 `issue88_do_sth`

–  小星星有很多个特性在同时开发，为了防止后续忘记每个分支的合并情况
–  小星星需预先提交一个以 `WIP: issue88 do sth` 为标题的 merge request
–  只要这个 merge request 没关闭，小星星就知道这个功能还没有合并
–  这样妈妈再也不用担心小星星辛苦开发的新功能忘记合并上线了！

2.  新功能开发的差不多了，宇哥想要 demo 验收
–  小星星将特性分支 `issue88_do_sth` 合并到体验分支 `playground`
–  体验分支会通过 CI 自动更新到 playground.devops.xsjom.com 环境
–  这时宇哥体验到了，然后提了一些宝贵意见
–  于是小星星继续改进特性分支 `issue88_do_sth`，然后重复上面的步骤

3. 宇哥表示这个新功能很好用，合到新版本 v3.0 里，发布到线上吧
– 于是小星星把之前的 WIP 的 merge request 修改为正式的请求了，并请蒋委员长做主
– 蒋委员长带着大伙一起审了代码，觉得没问题，就接受了这个 merge request
– 这时基准分支通过 CI 自动更新到 dev 预发布环境，这个环境里对各个开发者的新特性进行整合测试，防止功能冲突
– 预发布环境测试一段时间，发现没问题了，宇哥说“上”！
– 蒋委员长从 develop 合并到 master，并打上了标签 v3.0，v3.0 便正式上线了！

流程如下：

这次改进，我们增加了规范，增加了约束，也将各分支进行了良好的隔离。

版本更可控

团队一直在使用 Tower 做项目管理，每次有需求与任务时，我们会在 Tower 看板中进行跟踪。为了能和 Gitlab 结合起来，决定将 Gitlab 的 Milestones 完整的利用起来，通过制定每两周一线上发布的节奏，创建一个 Milestones，同时在 Tower 中创建相同版本号的看板。开大会讨论，将那些 issue 加到本次发布列表中。即保证高效，又有利于项目管理。

现在的问题？
1. issue 命名不够规范
2. commit 不够标准
3. 个人孵化项目缺少立项会
4. PR 集中在单点处理
5. 代码注释不全
6. 缺少单无测试
7. 缺少自动化测试

改进的流程，增加两个重要的测试：

通过几次不断的测验，完善，团队找到了属于自己的敏捷之道。

精益之道：

1. Tower 看板与 Milestones 保持高度一致
2. Tower 任务与 issue 保持高度一致
3. 分支命名采用：`15-require-a-password-to-change-it`
4. commit 采用：`git commit -m “create user model to store user session infomation” ` 。禁止使用：` “add user.rb”`
5. 提交 PR 或在 PRcommit 中加入 `fixes #14, closes #67`
6. 将个人提交的分支过多时，采用 git rebase  “衍合”后再提 PR 
7. 接收 PR 时，注意删除原分支