Merge Requests 管理说明

1. 提高全体综合技术水平，加快产品开发进度，保障产品质量。

2. 促进每个人的个人成长，技术成长，项目工程化水平。

3. 增进技术交流，倡导技能竞争精神。

1.使用 gitlib 的 MR 功能。功能开发完成后，向测试主分支合并代码时，使用合并请求，评审人评审并通过后，才可合并到测试主分支。

2. 各项目采取技术负责人制，提高技术负责人的全局代码参与度。由前后端技术负责人 Review 项目成员（可以是一个人），并在 git 系统内进行 MR (Merge ReQuests) 管理。

3. 相在的代码规范由 UEA 技术组起草制定，全体成员一起升级维护。

1. 项目代码库设置主分支，测试分支。

2. 每个人在自己分支下开发完成后，向测试分支提交合并请求。

3. 由技术负责人或项目自由指定的 Code Review 负责人审核代码，不符合规范要求、技术选型、存在技术问题等各种情况，在 Git 系统进行反馈，并驳回。

4. 开发人员再次完善修改代友，并提并代码后，重新提交“合并请求”。

5. Code Review 负责人再次审核，选择通过合并，或反馈意见。

1. 项目成员如果有对负责人评审不认可情况，可交由 UEA 技术组和技术人沟通确认。采取以理服人的辩论方式。

2. 代码规范相关的问题由 UEA 解答，如果编码规范不全时完善代码规范。技术问题采取多方论证，力求共同找到最优方式。

3. 其它 UEA 技术组参与仍然不能解决的情况。邀请各项目组相关技术一起投票决定。

对于在互联网行业耕耘的软件工程师，

学会思考是对其个人最大的奖励。

需要驱动其学习和成长，也许算是一种惩罚。

uea关于merge request的规范：

commit原则：

1 完成一个页面、功能时；或者当天下班提交一次；

2 必须有相关备注，未完成的提交可以加个前缀，如【temp 订单列表】

3 复杂的、修改内容较多的bug commit一次。

为使merge request更有意义，原则如下：

1 新功能开发阶段，可以在初步完成一个页面、功能时进行merge request。

2 不要积压很多功能再MR，会增加review复杂度。

3 描述MR包含内容，功能点等