标签：自动 分支 用例 交流 描述 远程 阅读 包含 release
最近在读一本技术类的书：朱赟——《跃迁：从技术到管理的硅谷路径》，其中聊了很多很有趣的观点，比如：技术管理、技术实践、硅谷文化、个人成长等。
读到关于硅谷人如何做code review这一篇时，不由想到了前段时间看过的一篇博客：如何写好Git commit log。
之前的工作用Git做版本管理工具，因此每次提交改动时都会写注释，其中也踩了一些坑，现在回想起来还是觉得很有收获。
这篇博客，聊聊我个人关于code review和Git commit的一些认知和资料总结，仅供参考。。。
参考资料：《跃迁：从技术到管理的硅谷路径》
一、聊聊code review
1、什么是code review
code review，即：代码审查。指在软件开发过程中，对源代码进行审查，目的是查找系统缺陷，保证软件总体质量，团队内部知识分享，提高开发者自身水平。
Code Review是轻量级代码评审，所需要的各种成本要明显低的多，如果流程正确，它可以起到更加积极的效果。
2、为什么要code review
①、提高软件代码质量；
②、及早发现潜在缺陷与BUG，降低风险成本；
③、促进团队内部知识共享，提高团队整体水平；
④、评审过程对于参与人员来说，也是一种思路重构的过程，帮助更多的人理解系统；
3、如何进行code review
①、code review目标和原则
发现代码的正确性
不仅是code review，更重要的是学习和分享
高效code review
②、有选择的进行code review
最近一次迭代开发的代码；
系统关键模块；
业务较复杂的模块；
缺陷率较高的模块；
③、code review的工作流
本篇博客主要介绍基于Git做版本管理工具的code review，因此以Git为例子说明。因为Git比较灵活，诞生了很多工作流，常见的有下面几种：
4、code review具体要做什么
检查代码设计体系的合理性和业务逻辑的正确性；
检查代码的可读性和可维护性；
检查代码的功能实现完整性；
检查代码的安全性；
5、code review注意事项
保持code review的目标单一性；
确保code review的代码都是经过测试且测试用例覆盖率较高；
不要刻意去寻找代码存在的缺陷；
不要强制别人遵循自己的编码风格和习惯；
不要抨击和批评，学会建议和学习；
不要在不确定的问题上花费太多时间；
学会倾听和理解别人的建议，同时经过思考再给别人提建议；
6、code review需要自顶向下的支持
制定统一的编码规范和风格；
统一代码管理和审核的流程与工具，并确保大家使用同样的工具，遵循既定的流程规范；
鼓励团队成员帮别人code review，甚至可以列入绩效评估之中；
二、聊聊Git commit
之前的博客介绍过Git基础使用教程和和Git分支管理规范，在每次代码改动之后，都需要将本地分支的代码提交到暂存区，编写commit log，然后推送到远程仓库。
所谓的commit log，就是对每次代码的改动进行说明和注释，示例如下：
编写commit log：
1 $ git commit -m ‘first commit‘
2 [master (root-commit) d8fedf7] first commit
3 28 files changed, 396 insertions(+)
查看commit log：
1 $ git log
2 commit d8fedf7548e2f1314e7bfc0ffc3a1d4612c83e9e (HEAD -> master, origin/master)
3 Author: laozhang <laozhang@163.com>
4 Date: Sat Aug 11 00:27:46 2018 +0800
5
6 first commit
编写commit log的好处有很多，比如：
提高code review的效率；
清晰的描述release分支内容，提升可读性；
......
总之，一个好的commit log可以对项目长期的进度提升以及质量管理带来很大帮助！
三、如何写Git commit log
1、对提交改动的代码做好分类
在进行code review之前，需要了解清楚这部分代码的核心功能是什么，然后针对性的进行审核 ，一般将提交的代码分为以下几种类型：
①、缺陷修复
②、代码优化
③、系统迁移
④、新功能实现
2、统一commit log的编写方法和规范
同一个团队，提交日志的方法应该一致 。为了创建一个清晰可用的修改历史，团队应该首先对提交信息的约定形成共识，至少明确以下三件事情：
①、风格：包含句语、自动换行间距、文法、大小写、拼写，最终的结果就是一份相当一致的日志，不仅可读性很好，而且可以定期阅读；
②、内容：哪些信息应该包含在提交信息的正文中，哪些不用，比如：文件的移动和拆分、函数重构等；
③、元数据：引用问题跟踪 ID，pull 请求编号等；
其他相关资料链接：
以上内容参考了很多其他同行的资料，个人做了一个整理和总结，仅供参考，如有更好的意见，请在评论区提出交流，谢谢。。。
标签：自动 分支 用例 交流 描述 远程 阅读 包含 release
原文地址：https://www.cnblogs.com/imyalost/p/9452559.html
