背景

• 1.项目混乱
• 2.人员流动性大
• 3.代码质量难以保证
• 4.现场需求多，版本发布频繁

什么是PR？

PR的全称是Pull Request，经常用 Github的同学对这个肯定很熟悉了。Github 聚集了4000万开发者，过亿的开源项目，如果想给别人的开源仓库贡献代码，通常是先 fork别人的项目，然后本地修改完成提交到自己的个人 fork 仓库，最后提交 PR 等待别人合入你的代码。

=

我们怎么用PR进行代码质量把控？

任何功能的开发需要在各个主干分支的基础上创建远程个人分支

• 每次开始开发前，merge目标主干分支的代码
• 开发自测

• 提交代码前处理所有格式报错
• 提交代码前从目标主干分支merge代码并解决冲突

• 更新版本（包括copyright的版本号和package.json的版本号）
• 分支命名统一为 主干分支名-个人姓名，如：dev1-gaoxl

分支策略建议（试行）

• master (稳定保底分支)
• release（测试通过对外发布的分支）
• develop（开发分支）
• develop-xxx（个人分支）

从个人远程分支发起合并请求到主干分支

发起PR规定

• 指派成员至少1人（目前仓库只支持一个人评审，先指定一个人，但是不可前后多次指定同一个人）
• 内容编辑中需提交如下信息：

1.需求/修复bug描述---可以是tapd链接或者现场问题截图
2.实际修复的模块截图，服务端变更也需要提供具体针对的模块和页面
3.前端提供可以测试的链接：可以是本地服务，也可以是测试环境的链接，和账号
  服务端同上或提供可供测试的接口api，并提供预计结果

• PR中的冲突需解决后重新提交
• 非修复上一个PR的问题，禁止在一个PR未审核通过时追加push

审核PR规定

• 每百行代码至少一条有效评论
• 发现任何质量问题或测试不通过评论后直接拒绝，修改后重新发起
• 审核人必须执行基本的测试用例后才可以通过
• 审核人要对代码质量负责，发现现场问题需要和PR发起着一起定位并解决问题
• 涉及到router、http等封装架构层面的变更，必须加上我（高雪凌）审核通过才可合并

PR合并

• 至少一个人审核通过后可以合并代码
• 合并代码后在主干分支打tag

特殊情况

• 主干分支1向主干分支2合并，需要从分支1拉个人分支，向分支2发起PR请求
• 主干分支向基线分支或者master合并，无需pr

最佳实践

PR中提出的问题，讨论价值后整理为最佳实践供后续参考

说明

1. 禁止私自改框架层面的代码直接发版，禁止没人评审通过+验证通过的代码直接发版。
2. 所有的bug修复及需求发版，至少保证组内一个人完全了解确认没问题后才可以对外。
3. 现场配合验证bug版本，禁止作为最终现场使用版本！！