Gerri Review Code Management specification

Gerrit Review and Hair Edition management

One: Gerrit Submit audit Code Flow

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

II: Gerrit Submit code specifications and Responsibilities

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

III: Gerrit code review personnel specifications and responsibilities

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

IV: Packaging personnel specifications and responsibilities

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

Five, administrator specifications and responsibilities

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

VI: Release version flowchart

Gerri Review Code Management specification