commit 规范性提交

添加 pre-commit 规范团队提交规范

• 增加 eslint + pre-commit
• 以前团队的 commit 都比较随意，没有对照和规范性。

安装

npm install --save-dev pre-commit

具体的详情可以看 github

• github.com/observing/p…

优点

• 可读性好，清晰，不必深入看代码即可了解当前 commit 的具体功能
• 为以后跟踪和查看 log 历史做准备
• code review 更加方便
• git blame（查看每个部分是谁修改的） 更加便捷

commit message格式

• 每次提交的时候都包括三个部分： header,body,footer
• header 是必填，body 和 footer 都是可省略的。

1、header

• header 分三个部分 type必填,scope选填，subject,选填

1.1、type

• build: 项目构建打包
• ci: 项目构建配置的变动
• docs: 仅仅修改了文档等（不是指文案类的改动，而是指项目文档、代码注释等）
• fix: 修复bug
• feat: 增加新功能
• perf: 优化
• refactor: 重构(非fix、非feature、非style风格格式化)
• revert: 代码回滚
• style: 代码风格变动，例如空格、缩进等（不是指css文件变动）
• test: 测试用例代码
• chore: 其他类型的更改（非即以上类型的改动）

上诉是一些基础类型

1.2、scope

• scope用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同。
• 例如在Angular，可以是

location,

browser,

compile,

rootScope, ngHref, ngClick, ngView等。

• 如果你的修改影响了不止一个scope，你可以使用*代替。

1.3、subject

• 对 commit 的简单描述

2、body

• 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

有两个注意点:

• 使用第一人称现在时，比如使用change而不是changed或changes。
• 永远别忘了第2行是空行
• 应该说明代码变动的动机，以及与以前行为的对比。

3、footer

• 如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE开头，后面是对变动的描述、以及变动理由和迁移方法。
• 关闭 Issue

demo

• 比如现在我们增加了一个项目(projectTest)的其中一个 button 组件
• 我们像这样来写 commit

git add .
git commit -m"feat: projectTest: add new component(button)"

• 上面只是一个在自己项目中的 commit ，根据不同的情况，pre-commit 根据自己的项目去配置一些规范 。

参考

• www.ruanyifeng.com/blog/2016/0…
• github.com/observing/p…