携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第36天，点击查看活动详情
commit message 在工程开发中有很重要的作用。一个好的 message 不仅仅能够降低 reviewer 的心智负担，也能够方便日后追踪问题。但写好一个 commit message 可不容易，今天这篇文章我们来思考一下怎样让 commit message 更加清晰，帮助业务团队提高效率。
commit 粒度
commit 本质就是一些代码变更的聚合体，我们可能在一个 commit 中改动多个文件。问题的关键在于 commit 的语义和粒度。
这个很多时候很头疼，大 commit 不好 review，每次一看到十几个文件上千行记录在一个 commit 里就很想哭。小 commit 本身是没问题的，但很多时候大家稍微改一点就提一个 commit，导致放眼望去全是意义不大的提交，记录基本没法看。
怎么把握这个度呢？
这里提供一个标准供大家参考：你的 commit 能得体地告诉别人干了一件什么事。
一件事
能拆的要拆，两个语义独立的改动不要放到一个 commit 里面，做好一件事即可，commit 的内容应该是高内聚的，不要出现夹带私活的情况。
只要保证你的 Merge Request 是干净的，信息清晰的就 ok，不要担心一个 MR 对应多个 commit 的问题，该合并就合并，但语义独立的两件事，不要合在一起写。
得体
不要随随便便改一个地方就提交一次，比如这里加了个空行，那里删了个注释，全拆开，倒的确是不同的事，但这样让别人看就很不得体。想象一下，你现在是个教练，本来可以等学员练习好了，看一遍效果给出评价即可，可你的学生每做一个动作就要把你拉过来看看，这时你是什么心态？肯定要崩溃！
软件开发也是如此，明明你是要开发一个需求，结果只有一个 commit 是真正支撑需求的，各种格式优化的 commit 多达十几个，这就非常不得体。
- 思考每一个 commit 是否必须。一定要记住，不要多写一行多余的代码，否则未来你会很纠结；
- 学会归纳。合并同类项。
message 格式
<type>(<scope>): <subject>
<空行>
<body>
<空行>
<footer>
type
type 就是 commit 的类型：
- docs: 文档变更
- feat: 新需求特性
- fix: 修复 bug
- perf: 性能提升
- style: 代码风格相关
- test: 测试代码修改
- refactor: 重构代码
- chore: 构建过程或辅助工具的变动，日常的修改
scope
scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。这个大家根据业务情况自行约定规范即可。
subject
commit message 的核心部分，说明干了一件什么事，标题性质，简单的修改要做到让大家一看标题就能理解改了什么。
body
对本次 commit 的详细描述，可以分成多行，说明代码变动的动机，以及与以前行为的对比，详细的背景要在这里说清楚。比如
More detailed explanatory text, if necessary. Wrap it to
about 72 characters or so.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Use a hanging indent
footer
只有在 break change 或者关闭 issue 时使用，场景较少，日常业务开发可以忽略。事实上，能把 subject，body 写好就不容易了。
内容多了怎么办
很多时候大家都直接用 git commit -m "xxx" 来代替，其实建议大家带上 body，很多 commit 光看 subject 跟没看是一样的。
这种情况下，大家直接用 git commit 来提交，跳出文本编辑器，支持大家输入 body。
一定记住，body 不是可有可无，一个优秀的 commit message 要能做到看了就知道前因后果，知道改动原因。而不是留一句片汤话在 subject 上。
语言选择
这一点很多团队会忽视，笔者待过的几乎每个团队，都是中英文混杂，这一点很不好。建议统一语言，如果公司规定开发必须用【英语】，ok 没问题，大家做好准备，提高英语素养，找到每个业务概念最精准的表达，形成规范，落地就行。
但是，但是！！！
绝大多数团队是做不到这一点的，因为没有动力，而且大家都是中国人，很多语言表达即便过了四六级，也很难很精准，于是写的五花八门。
与其这样，不如明确，除了 type，其他全用中文代替。
