Git 提交信息规范
为什么必要提交信息规范
使用 Git 作为版本管理工具时,我们常用git commit命令来提交代码
- [/code] shell
- 代码解读
- 复制代码
- git add . git commit -m "A bug fix"
- 使用-m参数来指定提交信息,即 commit message
- 一般来说,commit message 应当清楚明白,说明本次提交的目标。好的 commit message 可以资助快速查找梳理代码,辅助天生文档等
- 在 GitHub 社区中,commit message 有多种规范,此中 Angular 团队所使用的规范,称为 Angular 规范,目前使用比较普遍,并且有配套工具
- [size=3]Angular Commit Message 规范[/size]
-
- [align=center][img=952,860]https://img-blog.csdnimg.cn/img_convert/33e11b4f3294b21387a6fab36b18051d.webp?x-oss-process=image/format,png[/img][/align]
- [size=2]commit message 格式[/size]
- [code]
复制代码 xml
代码解读
复制代码
<type>(<scope>): <subject> // 空一行 <body> // 空一行 <footer>
第一行
只有一行,包括三个字段,type(必需)、scope(可选)和subject(必需)
type用于说明 commit 的种别,只答应使用下面7个标识。
- [/code] bash
- 代码解读
- 复制代码
- feat 新功能 fix 修复 bug docs 文档 style 调解代码格式 refactor 重构(非新增功能,也非 bug 修复的代码变更) perf 代码优化 test 增加测试 build 打包相干、外部依赖变更 ci 持续集成、自动构建相干变更 chore 其他改动(非 src,也非 test 的改动) revert 代码回退
- scope用于说明 commit 影响的范围,好比数据层、控制层、视图层等等,视项目差别而差别。
- subject是 commit 目标的简短形貌,不超过50个字符,以动词开头,使用第一人称现在时,好比add xxx
- 不管是哪一个部分,任何一行都不保举超过 72 个字符,制止自动换行影响显示效果
- [size=2]Body 部分[/size]
- 对本次 commit 的详细形貌,可以分成多行
- [size=2]Footer 部分[/size]
- 一般用于两种情况,破环性变更和关闭 issue
- 如果当前提交导致与之前版本不兼容,则 Footer 部分以BREAKING CHANGE开头,背面是对变更的形貌、以及变更来由和迁徙方法
- [code]
复制代码 yaml
代码解读
复制代码
BREAKING CHANGE: isolate scope bindings definition has changed. To migrate the code follow the example below: Before: scope: { myAttr: 'attribute', } After: scope: { myAttr: '@', } The removed `inject` wasn't generaly useful for directives so there should be no code using it.
如果当前 提交针对某个 issue,可以在 Footer 部分关闭这个 issue
- [/code] mipsasm
- 代码解读
- 复制代码
- Closes #234
- [size=4]Git Hooks[/size]
- [size=3]Git Hooks 简介[/size]
- Git 提供了多种差别类型的钩子(hooks),可以在特定的利用时执行自定义的脚本或命令
- [code]
复制代码 sql
代码解读
复制代码
pre-commit:在创建提交前运行,通常用于代码格式化、静态代码分析或运行单元测试等任务 prepare-commit-msg:在提交消息被编辑后但提交之前执行,通常用于验证或修改提交消息 commit-msg:在提交消息被编辑后但提交之前执行,用于强制执行提交消息格式规则 post-commit:在提交完成后执行,用于执行与提交相干的任务 pre-rebase:在进行 rebase 利用前执行,通常用于准备 rebase 过程 post-rewrite:在执行诸如 git commit --amend 或 git rebase 等利用后执行,用于与重写汗青相干的任务 pre-push:在推送利用前执行,用于在推送更改之前运行测试或代码查抄等任务 pre-receive:在远程仓库接收到推送利用时执行,通常用于验证或预处置惩罚 update:在服务器上接收推送利用并更新引用时执行,用于额外的验证或处置惩罚 post-receive:在接收到推送利用并完成更新后执行,用于执行后续任务
借助pre-commit或者commit-msg可以方便的对 Git 提交信息进行校验
Git Hooks 脚本文件一般放在.git/hooks目次下,文件名为特定的钩子名称,如commit-msg
在 Git 2.9 版本,引入了core.hooksPath的配置,可以自定义 hooks 脚本所在目次
- [/code] shell
- 代码解读
- 复制代码
- git config core.hooksPath "<path-to-git-hooks>"
- [size=3]commit-msg 脚本[/size]
- [code]
复制代码 shell
代码解读
复制代码
#!/bin/bash # 获取提交信息 commit_msg_file=$(git rev-parse --git-dir)/COMMIT_EDITMSG commit_msg=$(head -n 1 ${commit_msg_file}) # 使用正则匹配 Angular 提交日志格式 regex="^(feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert|wip|workflow|release)(\(.+\))?: .{1,72}$" if [[ ! ${commit_msg} =~ ${regex} ]]; then echo "Error: Commit message format does not comply with Angular commit message convention" echo "The correct format is: type(scope): short description (not exceeding 72 characters)" echo "For example: feat(core): Add new feature" exit 1 fi exit 0
Java 使用 Git Hooks
在 Java 项目中,可以使用 Git Hooks 脚本来校验 commit message,但是.git目次下的文件是不共享的,如果将脚本维护在项目布局目次中,必要手动复制或配置来使其生效,这就必要通过项目构建工具自动来完成
我们可以使用 maven 插件执行命令或者拷贝文件的功能来实现这一点,也可以使用专门的 Git Hooks 相干的插件
maven Git Hooks 插件
git-build-hook
- [/code] xml
- 代码解读
- 复制代码
- <plugin> <groupId>com.rudikershaw.gitbuildhook</groupId> <artifactId>git-build-hook-maven-plugin</artifactId> <version>3.5.0</version> <configuration> <gitConfig> <core.hooksPath>ci/git-hooks</core.hooksPath> </gitConfig> </configuration> <executions> <execution> <goals> <goal>configure</goal> </goals> </execution> </executions> </plugin>
- Git Hooks 相干文件放在ci/git-hooks目次下,在 maven 执行编译时,会自动配置到 hooksPath
- 当不按规范提交时提示
- [code]
复制代码 sql
代码解读
复制代码
> git commit -m "test msg" Error: Commit message format does not comply with Angular commit message convention The correct format is: type(scope): short description (not exceeding 72 characters) For example: feat(core): Add new feature
前端 Git 工程化
得益于丰富 NodeJs 的生态,前端在 Git 工程化、规范化方面有很多良好的工具可供使用
commitlint
commitlint 是用来校验 commit message 是否符合规范的工具
安装 commitlint
- [/code] shell
- 代码解读
- 复制代码
- npm install @commitlint/cli @commitlint/config-conventional -D
- 配置 commitlint
- [code]
复制代码 javascript
代码解读
复制代码
commitlint.config.js module.exports = { ignores: [commit => commit.includes('init')], extends: ['@commitlint/config-conventional'], rules: { 'body-leading-blank': [2, 'always'], 'footer-leading-blank': [1, 'always'], 'header-max-length': [2, 'always', 108], 'subject-empty': [2, 'never'], 'type-empty': [2, 'never'], 'type-enum': [ 2, 'always', [ 'feat', 'fix', 'perf', 'style', 'docs', 'test', 'refactor', 'build', 'ci', 'chore', 'revert', 'wip', 'workflow', 'types', 'release' ] ] } };
测试校验功能
- [/code] php
- 代码解读
- 复制代码
- > echo "aaa" | npx commitlint ⧗ input: aaa ✖ subject may not be empty [subject-empty] ✖ type may not be empty [type-empty] ✖ found 2 problems, 0 warnings ⓘ Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint
- [size=3]husky[/size]
- husky 是 NodeJs 中资助配置 Git Hooks 的工具,通过配置 husky 实现提交前的代码查抄、commit message 校验
- 安装 husky
- [code]
复制代码 shell
代码解读
复制代码
npm install husky -D
创建 husky 脚本文件
在.husky目次下,创建 pre-commit、commit-msg 脚本文件
- [/code] shell
- 代码解读
- 复制代码
- ### .husky/common.sh #!/bin/sh command_exists () { command -v "$1" >/dev/null 2>&1 } # Workaround for Windows 10, Git Bash and Pnpm if command_exists winpty && test -t 1; then exec < /dev/tty fi ### .husky/pre-commit #!/bin/sh . "$(dirname "$0")/_/husky.sh" . "$(dirname "$0")/common.sh" [ -n "$CI" ] && exit 0 PATH="/usr/local/bin:$PATH" # 执行 eslint fix npm run lint:fix ### .husky/commit-msg #!/bin/sh # shellcheck source=./_/husky.sh . "$(dirname "$0")/_/husky.sh" PATH="/usr/local/bin:$PATH" # 执行 commitlint 校验 npx --no-install commitlint --edit "$1"
- 配置 husky npm script
- [code]
复制代码 json
代码解读
复制代码
package.json "scripts": { "prepare": "husky" }
prepare 在执行npm install之前会自动调用,也可直接执行npm run prepare配置 husky hooks
lint-staged
在上面的 husky 脚本文件 pre-commit 中调用了 eslint 相干命令进行代码格式查抄和格式化,这往往是针对全体文件的,而 lint-staged 就是用来资助设定只查抄 Git 暂存区文件的工具
lint-staged 答应指定差别类型后缀文件执行差别指令的利用,如 eslint 或 stylelint
安装 lint-staged
- [/code] shell
- 代码解读
- 复制代码
- npm install lint-staged -D
- 配置 lint-staged
- [code]
复制代码 json
代码解读
复制代码
.lintstagedrc { "*.{js,jsx,ts,tsx}": [ "prettier --cache --ignore-unknown --write", "eslint --cache --fix" ], "{!(package)*.json,*.code-snippets,.!({browserslist,npm,nvm})*rc}": [ "prettier --cache --write--parser json" ], "package.json": ["prettier --cache --write"], "*.vue": [ "prettier --write", "eslint --cache --fix", "stylelint --fix --allow-empty-input" ], "*.{css,scss,html}": [ "prettier --cache --ignore-unknown --write", "stylelint --fix --allow-empty-input" ], "*.md": ["prettier --cache --ignore-unknown --write"] }
使用 lint-staged
- [/code] shell
- 代码解读
- 复制代码
- npx lin-staged
- [size=4]Git 命令行工具[/size]
- [size=3]commitizen[/size]
- commitizen 是用来代替git commit的工具,提供交互式命令行资助填写 commit message
- 安装 commitizen 和 cz-conventional-changelog 提交规范
- [code]
复制代码 shell
代码解读
复制代码
npm install commitizen cz-conventional-changelog -g
配置 commitizen
- [/code] shell
- 代码解读
- 复制代码
- ### ~/.csrc(全局安装时配置 ) { "path": "cz-conventional-changelog" } ### package.json(项目中安装时配置 ) "config": { "commitizen": { "path": "./node_modules/cz-conventional-changelog" } }
- 使用 commitzen,可以使用cz、git-cz、commitzen命令
-
- [align=center][img=1178,280]https://img-blog.csdnimg.cn/img_convert/dce8feceffa0135973c160b2312a9e72.webp?x-oss-process=image/format,png[/img][/align]
- [size=3]changelog[/size]
- changelog 指 conventional-changelog-cli,是资助从 Git 提交日志天生变更日志的工具
- 安装 conventional-changelog-cli
- [code]
复制代码 shell
代码解读
复制代码
npm install conventional-changelog-cli -g
使用conventional-changelog命令
[code][/code] shell
代码解读
复制代码
# 使用 angular 规范,在文件头部追加 changelog conventional-changelog -p angular -i CHANGELOG.md -s # 从头天生、覆盖旧的 changelog 文件 conventional-changelog -p angular -i CHANGELOG.md -s -r 0
原文链接:https://juejin.cn/post/7373609752238374975
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。 |