在团队开发中，提交代码内容说明，如果没有规范，那么我们如果想找历史版本就很难。如果有规范，团队中有人偷懒怎么办？那我们就要借助一些工具，做一些强制规定
通常情况下，我们一般会遵循Angular 规范，这是目前使用最广的写法，比较合理和系统化，并且有配套的工具。
Git message格式
Angular 规范的Git message格式组成：Commit message 都包括三个部分：Header，Body 和 Footer。
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
但是，我们一般只写Header,很少写Body 和Footer，这里我们着重介绍一下Header。
Header
Header部分只有一行，包括三个字段：type（必需）、scope（可选）和subject（必需）。
type
type用于说明 commit 的类别，只允许使用下面7个标识。
feat：新功能（feature）
fix：修补bug
docs：文档（documentation）
style： 格式（不影响代码运行的变动）
refactor：重构（即不是新增功能，也不是修改bug的代码变动）
test：增加测试
chore：构建过程或辅助工具的变动
如果type为feat和fix，则该 commit 将肯定出现在 Change log 之中。其他情况（docs、chore、style、refactor、test）由你决定，要不要放入 Change log，建议是不要。
scope
用于说明 commit 影响的范围，比如数据层、控制层、视图层等等，视项目不同而不同,一般也很少写。
subject
是 commit 目的的简短描述，不超过50个字符。
以动词开头，使用第一人称现在时，比如change，而不是changed或changes
第一个字母小写
结尾不加句号（.）
commitlint
我们通常使用commitlint工具去帮我们校验Git commit message是否规范。
Install commitlint cli and conventional config
For Mac
npm install --save-dev @commitlint/{config-conventional,cli}
# For Windows:
npm install --save-dev @commitlint/config-conventional @commitlint/cli
# Configure commitlint to use conventional config
echo "module.exports = {extends: ['@commitlint/config-conventional']}" > commitlint.config.js
To lint commits before they are created you can use Husky’s commit-msg hook:
# Install Husky v6
npm install husky --save-dev
# or
yarn add husky --dev
# Activate hooks
npx husky install
# or
yarn husky install
Add hook
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit ${1}'
扫一扫
908
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
