紫云飞的回答
commit message 甚至比注释更重要，一年前我发表过看法：
当时是我在推特上看到了 ladybird 浏览器 的作者，针对 HTML 解析器的 一个 PR 中的 commit message，进行了称赞。该 commit 只改动了一行代码，commit message 却写了 3000 字：
commit message 的重要性我感觉都不用解释，你有没有遇到过排查 bug 定位了到一个 commit，但是却不知道这个 commit 当时为什么要这么改？写这个 commit 的人可能是别人，也可能是自己，我是两种情况都遇到过。
国内的互联网公司里把 commit message 写好的人或者说项目几乎没有，我反正是没见过。很多人认为只写一行标题就可以了，但是一行标题只能用极短的句子总结这个 commit 干了什么，它仅仅是总结，而且更重要的是，标题解释不了为什么要这么改，所以需要写正文，即 body 部分。
除了不写正文部分，我看到 commit message 还有其它一些误区，我下面举例几个：
- 过分强调标题前面要加个 fix:、feat:、chore: 这种类型标签
比如 【fix: 修复某某 bug】、【feat: 实现了某某特性】这样的标题，本来标题就已经有“修复”、“实现”、“添加”等等字样了，加这种标签着实是没有实际功能。根据我的经验，一旦项目大到有多个模块，开头的标签更重要的是[模块名]，比如下面是 V8 的 commit 列表，标题会以 [regexp]、[heap]、[inspector] 这些开头：
2. 适合用中文描述的，非要用英文
很多项目都是业务代码，以后也不会有外国人参与，这种项目适合用中文，如果非要用英文，可能一些概念不好用英文表达，从而也会导致无法写的足够详细明了。
3. 使用工具检测，进行一些意义不大的限制
比如前面说的必须以 fix:/feat: 这些开头，还有更奇葩的是标题里不能包含大写字母开头的单词，否则就报错无法提交。其实像 chromium 这种上千人贡献的仓库，也没有任何强制要求，你的 commit message 可以是任意形式。
总结一下就是就是要从实际出发，不要盲目跟从一些表面的、形式化的做法。
git 方面还有其它一些好的实践，比如线性的 commit 序列，没有任何分叉、每次 review 只提交一个 commit。比起不知道怎么做是对的，更难的是国内的技术环境，如果你每天写的是一些没什么技术含量的业务代码，下个月都不一定维护了，谁他妈愿意花心思写 commit message。
相关文章
