提交信息规范
你将学会什么
Section titled “你将学会什么”- 套用最小可用模板：
<type>(<scope>): <subject> - 区分
feat、fix、docs、style、refactor、test的适用场景 - 写出一条“扫一眼就能懂”的提交说明
最省脑子的方式，不是规定成百上千条规则，而是给大学生一个最小可用模板：
<type>(<scope>): <subject>常见 type 可以是：feat、fix、docs、style、refactor、test。这样当你在期末项目里写提交历史时，老师或队友扫一眼就能知道哪一版新增了功能，哪一版只是改说明文档。
几条实际参考：
feat(quiz): 新增错题回顾功能—— 说明“做了什么”fix(form): 修复日期为空时的报错—— 说明“修了什么”docs(readme): 补充运行说明—— 说明“改了哪份文档”
写的时候记住一个原则：提交信息说明意图，而不是复述 diff。update file 这种信息等于没说；修复移动端按钮溢出 才是有用的信息。
先自己回答，再看答案：
feat和fix的区别是什么？- 为什么
update file不是一条好提交信息？ scope部分通常写什么？
参考答案
feat表示新增功能，fix表示修复问题。- 它没有说明意图，复述了 diff，回看时无法知道这次变更的意义。
- scope 写变更影响的模块或文件，如
form、readme、api。
- 模板固定为
<type>(<scope>): <subject>，type 用英文小写 - 提交信息说明意图，不重复 diff
- 统一规范后，扫
git log就能还原项目演进