Open mytac opened 6 years ago
之前我写过一篇有关于git提交的文档《用gitmoji来提交你的git commit吧》,然而在实际上应用并不是很方便,大多情况得翻阅gitmoji对照表来写commit,且并不规范,仅仅适用于自己开发的项目,放到团队上commit可读性不高。最近翻阅了一篇文章《你可能会忽略的 Git 提交规范》,才知道自己之前写的commit非常随意,在项目初期,写的还蛮正规的:
然而之后懒了,前面的tag也没加。(所以说,好的习惯要坚持,只要有一次没做,后面就容易堕怠)
去审查一下你自己的commit~如果你不习惯使用git GUI,在bash中运行以下命令:
$ git log [tag name/branch name] HEAD --pretty=format:%s
建议的格式如下:
<type>(<scope>): <subject>
用于声明此次commit的主要目的类别:
feat:feature、发布新功能 fix:修复bug docs:更新文档 style: 代码格式 refactor:代码重构 test:增加测试 chore:构建过程或辅助工具的变动
用于说明commit影响的范围;如数据层(model),视图层(view),控制层(controller)等。
commit的主题描述,少于50个字。
其实在《Commit message 和 Change log 编写指南》这篇文章中都有很详细的描述,文中也提到了commit message有body和footer,用于详细描述和关闭issue的补充。不过个人觉得在subject中写这些内容已经足够了。 了解git hooks 提到“hooks”这个词我们应该并不陌生,比如vue和react都有自己的lifecycle hooks,在git中分为客户端hooks和服务端hooks。在commit阶段中涉及到的是客户端hooks,其中客户端hooks包含: pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照,例如,检查是否有所遗漏,确保测试运行,以及核查代码。 如果该钩子以非零值退出,Git 将放弃此次提交,不过你可以用 git commit --no-verify 来绕过这个环节。 你可以利用该钩子,来检查代码风格是否一致(运行类似 lint 的程序)、尾随空白字符是否存在(自带的钩子就是这么做的),或新方法的文档是否适当。 prepare-commit-msg 钩子在启动提交信息编辑器之前,默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项:存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用;然而对那些会自动产生默认信息的提交,如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它,动态地插入信息。 commit-msg 钩子接收一个参数,此参数即上文提到的,存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出,Git 将放弃提交,因此,可以用来在提交通过前验证项目状态或提交信息。 post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数,但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。
其实在《Commit message 和 Change log 编写指南》这篇文章中都有很详细的描述,文中也提到了commit message有body和footer,用于详细描述和关闭issue的补充。不过个人觉得在subject中写这些内容已经足够了。
提到“hooks”这个词我们应该并不陌生,比如vue和react都有自己的lifecycle hooks,在git中分为客户端hooks和服务端hooks。在commit阶段中涉及到的是客户端hooks,其中客户端hooks包含:
“hooks”
vue
react
lifecycle hooks
客户端hooks
服务端hooks
pre-commit 钩子在键入提交信息前运行。 它用于检查即将提交的快照,例如,检查是否有所遗漏,确保测试运行,以及核查代码。 如果该钩子以非零值退出,Git 将放弃此次提交,不过你可以用 git commit --no-verify 来绕过这个环节。 你可以利用该钩子,来检查代码风格是否一致(运行类似 lint 的程序)、尾随空白字符是否存在(自带的钩子就是这么做的),或新方法的文档是否适当。
prepare-commit-msg 钩子在启动提交信息编辑器之前,默认信息被创建之后运行。 它允许你编辑提交者所看到的默认信息。 该钩子接收一些选项:存有当前提交信息的文件的路径、提交类型和修补提交的提交的 SHA-1 校验。 它对一般的提交来说并没有什么用;然而对那些会自动产生默认信息的提交,如提交信息模板、合并提交、压缩提交和修订提交等非常实用。 你可以结合提交模板来使用它,动态地插入信息。
commit-msg 钩子接收一个参数,此参数即上文提到的,存有当前提交信息的临时文件的路径。 如果该钩子脚本以非零值退出,Git 将放弃提交,因此,可以用来在提交通过前验证项目状态或提交信息。
post-commit 钩子在整个提交过程完成后运行。 它不接收任何参数,但你可以很容易地通过运行 git log -1 HEAD 来获得最后一次的提交信息。 该钩子一般用于通知之类的事情。
这里我们主要是在pre-commit阶段来检查commit是否符合规范。
pre-commit
在提交代码前需要格式代码,这里用git hooks:pre-commit。
针对暂存的git文件运行linters并且不要让垃圾代码滑入你的代码库!lint-staged的最新版本需要Node.js v6或更新版本。(在v7之前的lint-staged版本仍可与Node.js v4一起使用。)
在git hooks每个阶段执行脚本来避免垃圾代码的提交和push。 安装lint-staged和husky
lint-staged
husky
yarn add lint-staged husky
在package.json写入:
package.json
"scripts": { ... "precommit":"lint-staged" }, "lint-staged": { "*.js": ["eslint --fix","git add"] },
这时当你执行git commit操作时,一旦在暂存区存在eslint格式错误的代码,将会自动修复并加入缓存区(eslint --fix 无法自动修复的将会报错)。
git commit
如图:
这里我们使用另一个git hooks:commitmsg,我们来安装validate-commit-msg检查 Commit message 是否符合格式。
commitmsg
validate-commit-msg
yarn add validate-commit-msg
在package.json中配置:
"scripts": { ... "commitmsg": "validate-commit-msg" },
如果要进行自定义配置,我们可以自建一个文件.vcmrc:
.vcmrc
{ "types": ["feat", "fix", "docs", "style", "refactor", "perf", "test", "build", "ci", "chore", "revert",":art"], "scope": { "required": false, "allowed": ["*"], "validate": false, "multiple": false }, "warnOnFail": false, "maxSubjectLength": 100, "helpMessage": "", "autoFix": false }
随便写一个commit,会提示不符合规范。
让我们来写一个示例~
git commit -m "style: eslint"
测试一下,成功提交~~关于commit-msg这部分可以参考vue的commit.
写好commit也可以自动生成每个版本的更改,可以参考vue的changelog。
安装standard-version
yarn add standard-version
"scripts": { ... "release": "standard-version" },
在发布新版本的时候,运行以下命令:
yarn release
如果按照commitizen规范书写你的commit-msg,即可在你项目中自动生成changelog,如图:
前言
之前我写过一篇有关于git提交的文档《用gitmoji来提交你的git commit吧》,然而在实际上应用并不是很方便,大多情况得翻阅gitmoji对照表来写commit,且并不规范,仅仅适用于自己开发的项目,放到团队上commit可读性不高。最近翻阅了一篇文章《你可能会忽略的 Git 提交规范》,才知道自己之前写的commit非常随意,在项目初期,写的还蛮正规的:
然而之后懒了,前面的tag也没加。(所以说,好的习惯要坚持,只要有一次没做,后面就容易堕怠)
去审查一下你自己的commit~如果你不习惯使用git GUI,在bash中运行以下命令:
commit规则格式
建议的格式如下:
type
用于声明此次commit的主要目的类别:
scope
用于说明commit影响的范围;如数据层(model),视图层(view),控制层(controller)等。
subject
commit的主题描述,少于50个字。
这里我们主要是在
pre-commit
阶段来检查commit是否符合规范。提交前的配置
自动格式化代码
在提交代码前需要格式代码,这里用git hooks:
pre-commit
。lint-staged
针对暂存的git文件运行linters并且不要让垃圾代码滑入你的代码库!lint-staged的最新版本需要Node.js v6或更新版本。(在v7之前的lint-staged版本仍可与Node.js v4一起使用。)
husky
在git hooks每个阶段执行脚本来避免垃圾代码的提交和push。 安装
lint-staged
和husky
在
package.json
写入:这时当你执行
git commit
操作时,一旦在暂存区存在eslint格式错误的代码,将会自动修复并加入缓存区(eslint --fix 无法自动修复的将会报错)。如图:
规范化commit-msg
这里我们使用另一个git hooks:
commitmsg
,我们来安装validate-commit-msg
检查 Commit message 是否符合格式。在
package.json
中配置:如果要进行自定义配置,我们可以自建一个文件
.vcmrc
:随便写一个commit,会提示不符合规范。
让我们来写一个示例~
测试一下,成功提交~~关于commit-msg这部分可以参考vue的commit.
生成changelog
写好commit也可以自动生成每个版本的更改,可以参考vue的changelog。
配置步骤
安装standard-version
在
package.json
中配置:在发布新版本的时候,运行以下命令:
如果按照commitizen规范书写你的commit-msg,即可在你项目中自动生成changelog,如图:
参考文档