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权限
六：发布版本流程图
