基于Gitlab Issues为导向的分支管理

前言

Gitlab的开发分支流程规范对于日常开发十分重要，本文主要介绍下基于Issues为导向的中小型数据项目开发规范。

以Issues为导向的GIt开发规范

对于数据类项目，代码大多是Sql、Shell、Python脚本。各个模块、代码源文件关系不大，不会产生功能类错误，影响系统稳定性。因此可以采用以issue为导向的分支管理方法，来管控开发流程。大致流程如下：

 

1、开发人员根据需求提交Issue

开发人员A在Gitlab中首先提交一个Issue。填好Issue中的标题、描述：

同时可以填写Assignee指定这个Issue的解决人，Labels可以备注这个Issue是“confirmed”，“bug”，Due date至这个Issue的最终解决时间，点击提交Issue。

点击项目中的Issues列表，可以看到目前项目的主要问题：

2、代码审核人员查看Issue

开发人员A与代码审核人员A需要提前确认要改的Issue，比如“一个BUG标题”：

代码审核人员A如果认为bug确实需要修改，则在这个Issue中点击按钮“Create merge request and branch”，意思是 从master主分支拉取一个新分支“9-one-bug-fo-fix”（9代表Issue的id为9，one-bug-to-fix为命名的分支名称），专门来解决这个Issue反馈的BUG。

3、开发人员在分支“9-one-bug-fo-fix”上修改bug。

开发人员A打开IDE，下载代码，切换到“9-one-bug-fo-fix”，新增了“fixbug.py”文件，修改了BUG：

开发人员A将修改结果commit、push到分支“9-one-bug-fo-fix”。

此时代码审核人员A在web界面上可以实时看到开发人员A提交的修改：

 

其中"WIP"表示"Work In Process"，表示开发人员A正在修改代码，是不应该merge的。在下边栏Commits中，代码审核人员A可以看到开发人员A刚刚push的”fixbug.py“提交：

代码审核人员A可以点击页面中”#9“查看之前的Issue，确保开发人员A修改的代码在Issue修改范围内。

4、开发人员确认修改完成

开发人员A经过单元测试认为代码修改完成了，在web界面上点击”Resolve WIP status“，表示“9-one-bug-fo-fix”这个分支可以merge到master了：

此时Merge的按钮可以被点击。

5、代码审核人员将分支分支“9-one-bug-fo-fix”合并到master上

代码审核人员A查看代码没有问题后，确认可以合并到主分支上，点击Merge按钮。

此时页面由绿变为蓝，代表已经合并到主分支，同时会自动将Issue 9关闭：

6、查看git的分支图，可以发现”9-one-bug-fo-fix“已经提交到master上。

 

 

总结

总结下来，开发人员只需要先将BUG在Git上通过Issue描述清楚，然后在新分支修改上传代码即可。建立新分支，Merge等过程由代码审核人员完成。