十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
本篇内容介绍了“Git规范操作实例分析”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!
创新互联公司专注于企业全网营销推广、网站重做改版、京山网站定制设计、自适应品牌网站建设、HTML5、商城网站建设、集团公司官网建设、成都外贸网站建设、高端网站制作、响应式网页设计等建站业务,价格优惠性价比高,为京山等各大城市提供网站开发制作服务。
git commit message
即代码提交历史,错误的提交信息会影响代码的可维护性。在多人协作开发场景下因个人风格各有不同,若无统一的规范则很容易导致混乱。目前规范使用较多的是 Angular 团队的规范。
每个提交消息都包含一个header
、body
、footer
。header
具备一种特殊的格式,其中包括type
,scope
和subject
:
( ):
为使在各种git工具中更易于阅读,提交消息的任何一行都不能超过100个字符。
type
必需为以下之一开头:
feat:
一项新的功能feature
fix:
bug
修复
docs:
只修改了文档
style:
没有代码的更改,样式调整(空白,格式,缺少分号等)
refactor:
代码重构,既不修正bug
也不添加功能(feature
)的更改
perf:
改进性能的代码更改
test:
增加缺失或者更正现有测试
build:
影响构建系统或者外部依赖项的更改,如:gulp
, broccoli
, npm
ci:
对CI配置文件和脚本的更改,如:Travis,Circle,BrowserStack,SauceLabs
chore:
更改构建过程或者辅助工具和库,例如文档生成等
revert:
假如该提交复原了先前的提交,则应以revert:
开头 ,后接reverted commit
的header
。此外在body
中应该标明:This reverts commit
,其中hash是要复原的提交的SHA值。
scopescope
是可选的。
用于辅助说明所要提交代码更改的内容归属,例如可以指明是哪个位置(location
)、哪个模块(module
)、哪个组件(componet
)等。当更改影响的范围不止一个范围时,可以使用*
。
subject
该主题包含对变更的简洁形容:
使用现在时态:“change”不是“ changed”也不是“ changes”
不要大写第一个字母
末尾没有点(。)
就像在主题(subject
)中一样,使用命令式现在时态:“change”而不是“changed”或者“changes”。 body
应包括改变的动机,并将其与以前的行为进行比照。
不兼容变动
假如当前代码与上一个版本不兼容,则 Footer 部分以 BREAKING CHANGE 开头,用空格或者两个换行符,后面是对变动的形容、以及变动理由和迁移方法。如fix
并携带BREAKING CHANGE
信息:
fix: correct spelling of referrer in headerBREAKING CHANGE: Rather than using misspelled "Referer" as name of header,instead use correct spelling "Referrer". Clients expecting "Referer" will nolonger receive that header and will presumably not honor the new "Referrer"until updated to support this new name for this header.
关闭 Issue
假如当前 commit 针对某个issue,那么可以在 Footer 部分关闭这个关联issue 。
Closes #123
或者者关闭多个issue
Closes #123 #456 #789
现在比较流行的方案是商定式提交规范(Conventional Commits),它受到了 Angular 提交原则的启发,并在很大程度上以其为依据。笔者尝试查找了基于非node环境相关的Git规范化的辅助工具或者插件,并没有找到很好的处理方案,而我们假如拥有node环境非node项目也可以正常配置执行,只不过在工程中会生成node项目相关的文件,如node_modules
文件夹、package.json
文件等,因而在项目的版本控制中略微麻烦少量,根据需要定义自己的ingore
文件,解决好项目代码和环境代码的问题。
node
npm(npx)
commitizen/cz-cli:
是一个格式化commit message的工具,可以束缚提交者按照制定的规范一步一步的填写commit message。
cz-conventional-changelog:
为 commitizen 指定一个 Adapter ,一个符合 Angular 团队规范的 preset(按照我们指定的规范帮助我们生成 commit message)
定位到workspace
目录(即项目根目录)命令行输入npm init
,执行后会出现一系列初始化的提醒,可以一直回车至结束。
安装commitizen
和cz-conventional-changelog
npm i -D commitizen
npm i -D cz-conventional-changelog
修改package.json
文件
工程的配置示例.png
{ "name": "testp", "version": "1.0.0", "description": "", "main": "index.js", "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "commit": "git-cz" }, "config": { "commitizen": { "path": "node_modules/cz-conventional-changelog" } }, "author": "", "license": "ISC", "devDependencies": { "commitizen": "^4.2.3", "cz-conventional-changelog": "^3.3.0" }}
在项目根目录,命令行执行npm run commit
,会出现操作步骤提醒,按前文所诉填写规范化信息。
操作提醒.png
操作提醒..png
执行完,sourcetree效果图:
效果图.png
尽管我们在项目中配置了commit,但是假如我执行规范操作,不使用npm run commit
提交代码,通过命令行或者者Git可视化工具直接commit,那么提交上去的可能是不规范的信息,因而需要对git命令进行阻拦,并对message内容做lint操作。
lint工具依赖安装
commitlint/cli 【命令行工具】
commitlint/config-conventional 【校验规则】符合 Angular团队规范。
npm i -D @commitlint/config-conventional @commitlint/cli
修改 package.json
,配置commitlint
{ ... "scripts": { "test": "echo \"Error: no test specified\" && exit 1", "commit": "git-cz", "commit-lint": "commitlint -e $HUSKY_GIT_PARAMS" }, "config": { "commitizen": { "path": "node_modules/cz-conventional-changelog" } }, "commitlint": { "extends": [ "@commitlint/config-conventional" ] }, ...}
安装Husky
,进行git hooks
校验
npm install husky --save-dev
启用git hooks
npx husky install
git hooks
启用后会在项目根目录下生产.husky的文件夹
i
增加commit_msg
到husky,用于阻拦git commit
命令
npx husky add .husky/commit-msg "npm run commit-lint"
执行完成后会生成commit-msg
的脚本
commit-msg-shell.png
此时我们在命令行直接执行git commit -m "test message"
,会被阻拦提醒提交失败。
image.png
通过上面配置完成后用SourceTree提交代码会发现运行错误。
image.png
这是由于SourceTree没有读取到环境变量信息,需要在commit-msg
脚本中增加环境变量的配置。
image.png
#!/bin/sh. "$(dirname "$0")/_/husky.sh"export PATH=/usr/local/bin:$PATHnpm run commit-lint --silent
此刻再运行,已成功阻拦
cz-conventional-changelog
提交信息提醒和@commitlint/config-conventional
lint规则都可以设置自己设置的Adapter,可以根据自己需要配置适合自己团队的规范。
文章截图是以非node(Android)项目的视角进行的配置,其余项目也相似,只需使用的Git进行的版本控制,都可以实现Commit Message
的规范化校验。
文章依赖的是Mac OS,Windows下相似,所有的依赖库在Windows下也可运行工作,只不过环境的配置方式不同而已。
“Git规范操作实例分析”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联网站,小编将为大家输出更多高质量的实用文章!