gitLab工作流

一、分支功能和名称定义

1、master分支

生产分支测试无误，发版后，将生产分支，即develop分支，合并到master分支

2、develop分支（生产环境分支）

供测试使用，代表当前最新的可以测试的代码分支，feature分支代码被review后，都merge到develop分支，随时可以供测试使用。

3、feature分支

组内所有人日常开发和提交代码使用，提交完代码后，创建merge request请求，指定代码受让人和审阅人，代码被审查人审阅且没有任何问题后，会被受让人合并到develop分支。

3、release分支

最近一次发版的分支，线上出了问题后，可以在这个分支上进行修复，修复之后，合并到master分支，再从master分支合并到develop分支和feature分支。

二、协作流程

1、feature分支进行日常开发，开发完一个最小的能正常运行的粒度的功能后，创建一个merge request，指定代码受让人（对代码进行merge操作）和代码审查人（负责代码review工作）。在提交一个merge request后，且没有被审阅和merge前，后续提交的代码会

被更新到该merge request中。

2、代码审查人收到代码审查请求后，对代码进行审查，代码审查完成后，对代码进行merge。所以代码受让人和审查人都指定为同一人。

具体的代码review流程，参考下面标题三中的内容。

3、所有功能开发完成，测试无误后，将develop分支的代码合并到master和release分支。

上线前的打包工作，在master分支进行。

4、后续如果发现上一版本线上有bug,需要紧急修复，基于release分支创建一个bugfix分支，修复工作在bugfix分支进行，修复完进完基于release分支提交merge request ，在代码被审阅合并后，提交测试，上线后，删除bugfix分支，将release分支修改过的代码merge到master

、develop、feature分支。

三、创建merge request和代码review流程

1、在feature分支上开发代码,完成功能的最小粒度后，方可commit代码到featrue分支，

提交后，会返回这样一个链接，把该链接在浏览器中打开，就可以创建merge request了。

也可以提交代码后，在gitLab页面，选择相应分支的提交，创建merge request.

 

2、创建merge request

1）创建页面字段描述

• 1 from feature into develop ,将feature分支合并到develop分支，点击change branches,可以选择from和to的分支。

• 2 titile 默认为请求合并的分支名字。

• 3 默认为最近一个git commit 中的文字内容。

• 4 Assignee:受让人，主要职责，负责针对某个merge request，执行最终的merge操作。

• 5 Reviewer：主要负责代码的审查工作的人。

• 6、7、8不选择，具体含义，请查看gitLab相关文档。

• 9点击，Create merge request即可成功创建一个merge request。

• 在merge request被代码review以及完成完成merge 前，可以继续在当前分支commit代码，后期的commit将被更新到之前发起的  merge request当中。

• 我们这里，将Assignee和Reviewer指定为同一个人，方便及时的代码审查和合并。

3、代码review流程

1）被指定的Reviewer会收一个通知，具体位置如下图,在页面的右上角。

点击，可以看到如下

 

2)代码受让者的相关操作页面

Assigned to you 受让给你的merge reqquest，你有merge的权限，点击进入如下页面

点击话红色线的地方，进入merge request页面

 

3）代码审查者的相关操作页面

Review request for you 请求你负责本次merge request 的代码审查工作，点击进入如下页面

点击对应的条目，会看到如下页面

点击划横线的部分，进入和上述2）中的页面相同的工作页面。

所以，如果reviewer 有merge权限，可以进行和Assignee相同的工作。

即两者同时，既可以review代码也可以点击merge,进行代码合并操作。

这也是我们吧Assignee和Reviewer指定成同一个人的原因。

4)代码审查具体流程

代码阅读：

Commits 代表所有的历史Commit提交列表，选择某一个提交，可以显示本次提交发生了哪些变化。

点击Prev和Next可以查看之前的提交和后面一个提交发生的变化。

点击show lastest version，会跳转到最近一次提交发生的变化，一般,review代码的时候，我们选择show lastest version,因为我们只需要阅读所有提交的最近一次提交。

点击如果已经阅读完某个文件，点击右上角的viewed选择框，可以将文件折叠，方便阅读其它的文件。

 

关于下图中的页面设置按钮，大家自行点下所有的的按钮和选项，从字面意思和页面变化，大概就能知道是什么意思了。

4）添加阅读建议

光标悬浮在代码的某一行，会出现添加代码评论的提示和一个message图标，点击message 图标，可以对

该行代码进行点评

按住message对话框，拖动，可以对多行代码进行点评。

写好评论，点击start a preview ，允许创建在一个merge request内部创建comments,在发布之前只对你自己可见，目的是为了当你提交它们的时候只需要一次提交。

Add comment now:提交这个comment作为一个正常的comment，而不是本次review的一部分，可以立即被他人看见。

之后，可以看到如下界面

在后续的代码行新添加评论，可以点Add to review 将新的评论添加到当前review中

pending comments 将要被提交的comment列表。

Submit review 提交所拥有本次review过程中提交的comments，使它们对其他人可见。

最终，点Submit review ，提交所有评论，使所有评论对其他人可见。

提交后，可以在merge request页面的overview tab里面多出来关于评论的动态。

每一个评论，都对应一个thread。

 

5）关于thread

请参考文档，这里只做简单介绍

https://docs.gitlab.com/ee/user/discussions/#starting-a-review

• 什么是thread：thread可以看作因为某一个问题而被创建，在问题解决之后，被resolve的对象。

• thread的作用：thread可以跟踪进行中的计划的进度或者是code review的进度。

• thread和comment的关系：comment有两种创建方式，一种是标准的。另一种以thread形式创建的评论。

• 每一个thread，开始都被初始化成unsolved（未解决的），他们可以被至少是Developer权限的人或者本次代码的提交者，设置成resolved。如果thead被设置成resolved,非本项目的成员开发者，unresolved了他们的评论，thread会被设置成resolved.直到同一个回复被设置成resolved，整个的thread才被解决。

6）merge 代码

只有在resolve了所有的thread之后，merge按钮才会出现，这样做是为了跟踪整个代码review的流程。

这个是在全局做了设置，也可以设置成不需要resolve所有的thread也可以merge代码。

在merge 完成后，新写的代码，commit后仍然会生成新的merge request的链接。可以再次创建merge request.

四、gitLab的官方文档

https://docs.gitlab.com/ee/README.html

遇到任何问题，大家可以参考官方文档或者互相讨论。