|
提交PR时候有一个描述框，内容会自动根据Commit的message合并而成。
切记，如果一次提交的内容包含很多Commit，请不要使用自动生成的描述。
请用简短但是足够说明问题的语言（理想是控制在3句话之内）来描述：
你改动了什么，解决了什么问题，需要代码审查的人留意那些影响比较大的改动。
特别需要留意，如果对基础、公共的组件进行了改动，一定要另起一行特别说明。
审核人员邀请原则：
1. 在创建PR时，Reviewers（审核人）一栏里主要填写“必需审核人”。只有这些人审核都通过，才允许合并。
2. 除了“必需审核人”外，还有一些其它审核人，我们可以在Description里做为“邀请审核嘉宾”@进来。
3. 主干分支间的合并，如Develop => Master，或Master => Develop等，则需要把整个团队（开发+QA）都列为“必需审核人”。
必须审核人的列表由团队决定，可能包括以下人选：
- 团队Leader
- 前端架构师（如果有前端代码改动） （可以授权）
- 后端架构师（如果有后端代码改动） （可以授权）
- 产品架构师
- 对此PR解决的问题比较熟悉的（之前一直负责这部分业务的同事）
- 此PR解决的问题对他影响比较大（比如认领的任务依赖此PR的同事）
其它审核人，包括但不限于：
需要知悉此处代码改动的人但又不必非要其审核通过的同事
可以从这个PR中学习的同事
可以授权指的是，根据约定，Bug修复之类的改动，或者影响较小的改动，前端架构师和后端架构师可以授权团队内的某个资深开发人员，由这个资深开发人员代表他们进行审核。
主干分支之间的合并，大型Feature的合并，前端架构师和后端架构师需要参与。
上述审核人关注的视角不太一样：
团队Leader关注你是否完成了任务，前后端架构师关注是否符合公司统一的架构、风格、质量，产品架构师从整个产品层面来关注这个PR。
熟悉此问题的同事可以更好的保证问题被解决，确保没有引入新问题。
被影响的同事可以及时了解他受到的影响。 （编辑：安卓应用网_ASP源码网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
