Gerri review 代码管理规范

Gerrit review和发版管理

一：Gerrit提交审核代码流程

1.代码作者设置本地工作环境
2.从公开代码库同步代码到本地
3.代码开发者开发代码，提交代码
4.代码作者将代码提交到Gerrit缓存仓库，进入审核流程
5.代码作者指定相应的审核者来审核代码
6.审核者通过Gerrit查看代码修改，以确定是否符合要求？
7.符合要求就合并到Gerrit分支上，不符合要求就拒绝合并，让代码作者修改后重新提交

二：Gerrit提交代码规范和职责

1.所有的代码提交都是原子提交，尽量做到一个小功能一次提交，提交的代码需要规范，编码规范请参照附件文档。
2.每次commit的描述信息需要真实规范，如果是修改bug，请写上禅道的bug编号；功能性的提交，请写上具体功能。不允许出现不清晰的描述，出现3次以上会有相应的处罚。
3.操作reset命令后，commit的时候不能提交不是自己修改的class。
4.提交前本地运行以验证代码的完善性，做到程序无明显bug并且不会crash。
5.通知代码审核者审核代码。
6.代码审核完成后，pull最新代码，运行并检测代码是否与其他地方会产生冲突。   
7.每天下午5点准时打包，5点后尽量不要提交功能性的代码修改，如果需要提交也可以，但是代码审核人员不会合并到分支上去。只有得到打包人员通知有bug后，才能修改bug提交代码，以便打包工作的顺利完成。打包完成后可以恢复提交所有代码。

三：Gerrit代码审核人员规范和职责

1.尽量及时审核代码，以免产生conflict。
2.审核代码时要求书写规范（规范请参照附件文档），没有明显的逻辑错误。
3.审核完成后运行程序，验证代码正确性，确认不是产生crash和其他error。
4.每天下午5点后，原则上拒绝所有成员的功能性的修改，成员提交的代码review后，暂时不submit到分支上，只有在得到打包人员的通知程序有bug后，才能提交修改的bug，以确保打包能及时，高效的完成。

四：打包人员规范和职责

1.每天下午5点准时打包，打包前20分钟通知所有人员提交代码，5点过后，没有重大bug，不需要等待其他人员提交代码。
2.pull最新代码，运行程序发现有crash和其他error情况下，通知部门负责任，修改相应代码。
3.确认没有crash和其他重大error时，打包，上传到m3.syswin.com服务器。通过TeamBition通知所有部门进行测试，得到测试反馈没有重大问题后，提交到m1服务器上
4.，通过TempBition通知测试部门和整个研发中心人员测试新包，TempBition描述信息需要包括：
   （1）当前版本号
   （2）当前修改的bug和新功能
   （3）下载服务器地址

5.打完包后，必须打tag日志，以确保代码可以回滚，以下是打tag日志命令：
  (1). $ git tag -a 打包具体版本号 -m "打包具体版本号" 
  (2). $ git push origin -tags

五，管理员规范和职责

1.每天5点打包时，禁止所有代码审核人员submit的权限，当得到打包人员的通知有bug后，放开有bug部门的submit权限，以确保打包工作顺利进行
2.有紧急功能需要添加时，放开submit权限

六：发布版本流程图

转载于:https://www.cnblogs.com/likuiliang/p/4772278.html