拯救垃圾代码基于 Gitlab 的代码审查,简单实用
code review 的目的是提高代码质量,减少开发bug,俗话说,三人行必有我师,众人拾柴火焰高。
gitlab提供了code review机制,对基于gitlab的code review,直接以具体例子的形式做个实践总结。
gitlab提供了两种代码merge机制:
1)在本地将源分支(Source branch)代码合并到目标分支(Target branch),然后Push到目标分支(Target branch)
2)将源分支(Source branch)Push到远端,然后在GitLab指定目标分支(Target branch)发起Merge Request,对目标分支(Target branch)拥有merge权限的用户执行Merge操作,完成合并。
这两种方式仅有第2种适合code review,所以我们要做的事情是设置权限,拒绝本地merge后push到远端的操作。
在第2种方式中 发起merge request后,由有merge权限用户做code review,通过后执行merge操作。
具体操作如正文
一,分支设置
第一步,创建项目和分支。
分支结构和功能依据具体团队的规范来定,这里仅供参考。
推荐阅读:大厂 Git 提交规范是怎么做的?
关注微信公众号:Java技术栈,在后台回复:git,可以获取我整理的 N 篇最新 Git 教程,都是干货。
创建项目并创建分支如下
其中 release为预发布分支,develop为测试分支,develop-1为开发分支。
release,develop,master都是固定的分支,有固定的功能。
本例中假设流程开发如下:
1. 每次需要新feature时,从master拉取开发分支,比如develop-1。
2. master有更新及时合并到develop-1,develop,以及release。
3. develop-1开发完成后合并到develop,部署测试环境。
4. develop环境测试通过后,合并develop-1代码到release环境,做预发布测试。
5. release环境测试通过后,将develop-1代码合并到master,上线。
第二步,设置分支merge权限
这一步的是实现code review的关键,也就是控制分支的merge 权限。之后只有有merge权限的责任人才能submit merge请求,没有merge权限的只能提交merge请求,等待有权限的review后submit,则合并成功
具体设置位置:
项目首页→Settings->Repository→Protected Branches
将master,develop,release三个分支设置成只允许maintainers merge,不允许任何人push,也即在杜绝了上文说的从本地merge,push到远端的情况
二、具体操作
这里描述从代码修改,提交,发起merge请求,到code review后merge submit的整体流程。
第一步 开发分支代码修改,提交,push到远端
feature的开发分支不做具体的保护设置,即开发人员可以修改后,add,commit,push origin,这里不做详细讲解,push之后,可以在分支页面看到相应commit日志。如下。
第二步 create merge request
注意上图右上角有一个按钮,create merge request,发起merge请求后,进到页面。
选择source branch 和Target branch,这里我选择的是develop-1到release(假设到了预上线阶段),点击compare branches and continue。
页面中选择Assignee,指定reviewer,指定人会受到邮件。下面的approvers以及Approvals required,是批准人和最少批准个数。
填写Approvals required后,必须经过指定个数以上的人批准才能合并。
点击submit merge request。进到merge request页面。
第三步 code review
收到邮件的reviewer通过merge request 页面可以看到代码修改记录,并增加commond,其他人也可以通过commond进行讨论。
无问题可以点击merge通过或者不通过则点击右下角的close merge request。
第四步 查看所有merge请求
在项目页面的merge request页面可以看到所有open状态,close状态和merged状态的merge 请求。
推荐阅读:Code Review两年实战经验分享。
三、可能遇到的问题
遇到冲突怎么办
多个分支向一个分支合并代码等流程中,往往会形成版本冲突。此时,提交merge request后的页面如下:
我们发现,merge按钮置灰,同时出现了resolve conflicts以及merge locally的按钮。点击resolve conflicts。出现解决冲突的页面
页面可以通过use ours指定使用当前分支(发起merge request的源分支)代码或者use theirs来指定使用目标分支代码。或者点击 edit inline直接通过编辑页面编辑(更通用)。
ok,我们已经处理完冲突,点击下方submit按钮。 返回merge request页面,等待远端冲突解决完成后,merge按钮正常。
四、总结。
1. 关于分支设置
以上仅是一个分支设置的示例,我们可以根据团队风格,和具体问题具体分析。
比如多人同时开发一个需求,可能需要拉取一个feature分支后再根据该feature分支拉取个人开发分支,开发完成后和并feature再合并develop,release,master等
2. code review 流程
总结下code review流程
1)创建好 测试分支,release分支,并配置测试分支,release分支,master分支的merge权限
2)开发分支开发完成后push到远端,通过页面提交merge request,指定reviewer和审批人,一般指定reviewer即可。
3)reviewer 通过代码review,没有问题,可以点击merge,完成合并操作。如果有问题,可以发起讨论,或者直接关闭merge请求。
code review 流程完成。
作者:刘凯_7013 https://www.jianshu.com/p/5d764b52ea88
END
上一篇: [C#图解教程]笔记 - 20.异步编程
推荐阅读
-
像首席技术官一样思考:如何高效管理 30 人的研发团队?-管理越多越轻松。好的研发团队,应该是上拨下用,即下级对上级的向上管理;而不是反过来,总是向下管理,甚至是 CTO 做经理的事,经理做工程师的事,工程师最终会被当成实习生。如果是这样,就会越管越累,不仅团队无法成长,而且团队整天很忙还效率低下,问题一大堆。 有这样一个小故事:一位高级经理下班后帮忙倒垃圾,结果被老板训斥了一顿。这就好比首席技术官做了实习生自己该做的事。事情本身没有对错之分,只是从不同的角度有不同的理解。 古人云:"用人不疑,疑人不用"。在面对自己的研发团队时,应该相信他们能做好,授权一线开发人员充分发挥专业特长,不要限制他们的工作。但在相信他们的同时,也要进行二次确认,始终秉持 "我相信,但我要确认 "的原则和严谨的精神。因为每个人都会犯错和疏忽,通过发挥团队的智慧,团队犯错的机会就会大大减少。比如回归测试、代码审查、开发演示、变更审批等等。 如前所述,每个人都难免会犯错。但作为管理者,你所设计和商定的流程不能出错。管理者的每一个决定和沟通都应该经过深思熟虑。就像红绿灯的交通设计,某辆车不小心闯红灯可能会扣分,但红绿灯的设计一定要正确、人性化、统一。再比如,开发人员可能会因为疏忽大意写出 bug,但研发流程的设计和上线流程的发布不能有任何差错。因此,流程体系的设计,一方面要结合当前团队规模、业务特点和需要重点解决的问题来设计,另一方面也要在人员防错、效率提升、发挥团队集体智慧等维度进行综合考量。应该站在更高更抽象的角度去思考,不断思考一个倍受欢迎的园区应该如何设计,思考一个灵动、经典、永恒的建筑应该遵循怎样的模式,思考一个成功、优秀、卓越的研发团队应该需要怎样的流程和制度。 最后,反馈很重要。向上汇报很重要,向下反馈也很重要。能够保持顺畅的双向反馈和闭环管理,对研发团队的协作和沟通有着非常明显的积极作用。在向上汇报方面,要培养团队在正式汇报、会议汇报、私下沟通、书面总结、非正式场合等方面的沟通能力,提醒下属报喜也要报忧。凡事先记录,再跟进,最后反馈。反馈很重要,主动汇报更难得。 另一方面,同时也不要忽视向下反馈。好的爱,是双向的。团队也是如此,没有严格的上下级之分,只是分工和角色不同而已。作为管理者,不必总保持一种 "神秘感",让人 "捉摸不透 "才是牛。当团队做得好或有人做得好时,要记得在公开或私下场合给予肯定和赞许。业务有增长、业绩有提升时,别忘了给团队一些鼓励,或者安排一次下午茶或聚餐。在例会或正式会议上,也可以同步向大家传达一些重要信息和高层指示。"欲速则不达,欲远则同行"。 当向上汇报、向下反馈的沟通闭环形成后,同时结合前面研发过程的管理闭环,双管齐下,就能形成良性循环。如此反复,持之以恒,优秀卓越的研发团队,必将呈现。 能力、产出和效率 接下来,继续重复关于能力、产出和效率的话题。 站在不同的角色,以及一个企业经营、生存和发展所需要的基础上,我把研发生产力分为三个层次,分别是:一线员工关心的研发能力、管理层关心的软件产出和操作人员关心的企业生产效率。简单概括就是:既要把工作做好,又要能出成果,还要能帮企业赚钱。
-
拯救垃圾代码基于 Gitlab 的代码审查,简单实用