最近在读一本技术类的书：朱赟——《跃迁：从技术到管理的硅谷路径》，其中聊了很多很有趣的观点，比如：技术管理、技术实践、硅谷文化、个人成长等。
读到关于硅谷人如何做code review这一篇时，不由想到了前段时间看过的一篇博客：如何写好Git commit log。
之前的工作用Git做版本管理工具，因此每次提交改动时都会写注释，其中也踩了一些坑，现在回想起来还是觉得很有收获。
这篇博客，聊聊我个人关于code review和Git commit的一些认知和资料总结，仅供参考。。。
参考资料：《跃迁：从技术到管理的硅谷路径》
博客：如何写好Git commit log
一、聊聊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比较灵活，诞生了很多工作流，常见的有下面几种：
Forking工作流
Gitflow工作流
功能分支工作流
集中式工作流
Pull Request工作流
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
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 请求编号等；
其他相关资料链接：
code review应该怎么做
我们是怎么做code review的
如何进行高效的code review
以上内容参考了很多其他同行的资料，个人做了一个整理和总结，仅供参考，如有更好的意见，请在评论区提出交流，谢谢。。。