一、分支功能和名称定义
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
遇到任何问题,大家可以参考官方文档或者互相讨论。