
如果你是 PR 的作者
1. PR 不宜过大
2. 自我审查
3. 去掉不必要的文件
4. 创建有意义的标题
5. 有意义的描述
-
变更概述。你需要说明的 PR 中没有包含的方案(经过评估后被放弃的替代方法)。这样可以避免与审核代码的人重复讨论你已经尝试过的方案。
-
面向审核者的问题/注释。你希望审核者对于哪些代码提供一些具体的建议?代码的哪些部分很安全,可以忽略?你重构了哪部分代码,变动的文件虽然很多,但没有任何功能上的影响。告诉审核者可以放心地跳过哪部分 PR,他们会非常感谢你。
-
如何测试/演示。对于 QA 来说,这样的说明非常便利,比如预发布环境中的用户和密码、配置和设置说明等等,任何可以帮助审核者测试修改的内容。
-
附件:屏幕截图和视频。图片和视频的表达能力更强。变化前后的演示非常便利
。
6. 确认每条评论
7. 合并需要征求每个人的同意
如果你是审查者
8. 签出代码
9. 阅读标题和说明
10. 在本地验证你的建议
11. 如果建议太大,就直接写成 PR
12. 抵制评论的冲动
13. 如果没有更好的替代方案,请不要发表评论
14. 要有信心,不要偷懒
15. 修改代码之前先模仿原来的风格
16. 挑剔是好事
17. 面对面的交流
18. 心平气和
19. 没有紧急的 PR
-
异步交流。开发人员可以随时进行审查和响应,这样可以避免自己的工作被打断或受干扰。
-
质量保证。在代码进入目标分支之前,对其进行检查和测试,以确保目标分支保持干净。通过队友发现日常使用的代码中的潜在问题。
-
总结
微信公众号官方矩阵
本篇文章来源于微信公众号:GitHub科技
原创文章,作者:software,如若转载,请注明出处:https://www.sldh123.com/1748.html