3、在各个分支遇到的bug，请基于该分支创建一个Bug分支。
      如果在缺陷跟踪管理系统上有对应的项，命名请使用缺陷跟踪管理系统的ID，比如BAZABUG-1354 比如这个Bug的分支命名就是bugfix/BAZABUG-1354。
      如果在缺陷跟踪管理系统上没有对应的项，命名请简短的说明修改内容，比如“JX 9df2b01 引用bootstrap css虚拟路径重写，避免出现字体无法找到的问题”，分支命名可以是bugfix/miss-font。
      完成修改以后提交并推送到中心仓库然后立即向上游分支提交pull request。
4、发起pull request以后，请将pull request的链接在IM上发给代码审核者，以此通知对方及时进行审核。

二、执行

我们在团队内部提倡质量优先，开发团队不能为了进度牺牲质量，并在团队内部达成了共识。
所以，无论进度有多么紧迫，Code Review的过程都一定会做。
所有的问题一定会被提出，只是会根据进度的紧迫程度，以及问题的大小，改动成本，决定问题是现在解决，还是加一个TODO，并记录在缺陷跟踪管理系统内，以防日后遗忘。
多数情况下，我们都会要求立即解决，哪怕因此造成了发布的推迟。
我们深知，其实多数情况下，现在不解决，日后不知道猴年马月才能解决。

我们在团队内推行Code Review的过程中没有遇到太多阻力。
原因大概有两点，首先管理层方面了解之前遇到的各种问题，也迫切希望能有所改善，所以从一开始就是支持的态度。
其次，绝大部分开发人员觉得在这个过程中能自己能学习到东西，并没有抵触，遇到很好的意见时大家都还是很高兴的。
最后，慢慢的形成了一种氛围，整个团队都会自觉的维护它。
附一张我们审核的对话图，这位童鞋尝试对系统内部散落各地发业务邮件的代码做一个整理，用一套模式来处理，调整了3版才定调，然后修改了很多细节才通过了合并，前后大概用一个多星期时间：

表面上看来Code Review会延缓项目的进度，但是在我们2年多的执行过程中，大多数时候没感觉到有延缓。
原因是，虽然代码合并的周期变长了，但是由于代码质量提高了，导致Bug变少了，由于Bug引起的返工问题也变少了，因此整体的进度其实并没有延缓。
我个人认为对一个成熟的团队其实做Code Review反而会加快整体的项目进度，但是手头上没有统计数据支撑我的观点。（对于软件开发的度量，欢迎有心得的同学告知我）

我们每个分支有权限合并的人都不止一个，这样可以保证有人请假不在的时候，代码仍然可以被其他同事审核通过之后合并。

半年前，我们团队加入了很多新成员，刚加入的新同事对规范、项目、产品的熟悉程度都不高，导致了有一段时间，我们遇到了PR审核周期变长的问题。
加上之前遇到的一些问题，我们总结了一个说明，目的是减轻Code Review对开发人员工作的负担，加快PR审核通过的过程。
说明如下： 

Pull Request 的说明 

任务完成才能提交PR。
PR应该在一个工作日内被合并或者被拒绝。
PR在有严重问题（包括但不限于架构问题、安全问题、设计问题），太多问题，或者任务无效的情况下会被拒绝。
严禁一个PR里面有多个任务，除非它们是紧密关联的。
PR提交之后只允许针对Review发现问题再次提交代码，除非有充足的理由，严禁在同一个PR中再次提交其它任务的代码。 

（编辑：安卓应用网_ASP源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!