添加 pre-commit 规范团队提交规范
- 增加 eslint + pre-commit
- 以前团队的 commit 都比较随意，没有对照和规范性。
安装
npm install --save-dev pre-commit
具体的详情可以看 github
优点
- 可读性好，清晰，不必深入看代码即可了解当前 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，可以是
browser,
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 根据自己的项目去配置一些规范 。
