用 git 钩子,检测代码规范性(eslint、standard),让代码更规范

最终实现效果说明:

用 git commit 提交代码之前,利用 pre-commit git 钩子,实现代码规范检测(eslint、standard 规范),符合规范之后才可以提交到 git 仓库。这样在团队合作开发时,可以统一代码风格,如果某些同志代码不符合规范,是无法进行提交代码的。

我的demo地址:

demo地址

规范doc:

standard规范 eslint规范

git 钩子

git 钩子

那么问题来了,这种验证是如何实现的呢?!

请确保已经安装了: node | npm | git 安装传送门:node | npm | git

先说一下我的目录结构:

               |——node_modules            # 项目资源依赖(npm install 之后出现改文件夹)
               |
pre-commit ——— |——src —— test.js          # 项目代码(项目业务逻辑)
               |
               |——package.json            # 本地安装 npm 包 (npm init 之后出现该文件)
复制代码
一、 standard 规范验证,步骤如下:
  • 先按照鄙人的目录先创建目录,然后先后执行如下命令:
   git init                                    // 将本地项目设置为 git 项目
   git remote add origin url                   // url 为自己的 git 仓库地址
   npm init                                    // 将 pre-commit 项目设置为 npm 项目
   npm install --save-dev standard             // 安装 standard 规范
   npm install --save-dev husky@next           // 安装 husky git 钩子
   npm install --save-dev snazzy               // 安装 snazzy ,美化 standard 报错提示,eslint 规范不需要安装
复制代码
  • 安装好依赖资源后,更改 package.json 文件
// package.json
{
 "husky": {
   "hooks": {
     "pre-commit": "standard \"src/**/*.{js,vue,wpy}\" | snazzy",
   }
 }
}
注:检测 src 目录下的所有文件后缀为 .js || .vue || .wpy 的文件编码,是否符合规范。
若不符合,git 钩子将会阻止 git 继续 commit, 并且会报出错误信息;
若符合代码规范,git commit 就会成功提交到本地仓库。
复制代码

当然你可以绕过代码检测强制提交:

git add . && git commit --no-verify -m "代码规范强制提交测试"
复制代码

standard 规范错误提示如下:

// standard 规范默认错误提示:
D:\pre-commit\src\test.js:2:19: Extra semicolon.
------------------------------------------------
// 利用 snazzy 美化后的错误提示:
2:19  error  Extra semicolon
✖ 1 problem
复制代码
二、eslint 规范验证,步骤如下:
  • 先按照鄙人的目录先创建目录,然后先后执行如下命令:
   git init                                    // 将本地项目设置为 git 项目
   git remote add origin url                   // url 为自己的 git 仓库地址
   npm init                                    // 将 pre-commit 项目设置为 npm 项目
   npm install --save-dev eslint               // 安装 eslint 规范
   npm install --save-dev husky@next           // 安装 husky git 钩子
   
   注意,执行命令:
   $ ./node_modules/.bin/eslint --init         // 生成 .eslintrc.js 文件,可自定义代码风格
复制代码
注:eslint 自定义代码规范详情 [传送门](https://segmentfault.com/a/1190000011451121);.eslintrc.js配置详解[传送门](https://juejin.im/entry/59a43c86f265da246c4a28c0)
复制代码
  • 安装好依赖资源后,更改 package.json 文件
// package.json
{
 "husky": {
   "hooks": {
     "pre-commit": "eslint \"src/**/*.{js,vue,wpy}\"",
   }
 }
}
复制代码
当然你可以绕过代码检测强制提交:
git add . && git commit --no-verify -m "代码规范强制提交测试"

复制代码

eslint 规范错误提示如下:

// eslint 规范错误提示

D:\fe\pre-commit\src\test.js
  1:13  error  Strings must use doublequote                     quotes
  1:28  error  Expected linebreaks to be 'LF' but found 'CRLF'  linebreak-style
  1:28  error  Missing semicolon                                semi
  2:1   error  Unexpected console statement                     no-console
  2:20  error  Expected linebreaks to be 'LF' but found 'CRLF'  linebreak-style

✖ 5 problems (5 errors, 0 warnings)
✖ 1 problem
复制代码

按照相应的错提示,更改代码,符合规范后,即可提交到 git 仓库。

欢迎访问我的 git 博客:传送门,您的 star 是我最大的动力!谢谢!

声明:有任何问题欢迎留言!未经作者同意禁止转载!

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Windows Gitblit是一个基于Git代码管理工具,用于版本控制和团队协作。下面是一些关于Windows Gitblit代码上传的规范: 1. 提交频率:代码提交应该尽量频繁,每次提交应该包含一次有意义的代码改。这有助于确保代码版本的准确性和可追溯性。 2. 提交说明:每次提交都应该包含有意义的提交说明,明确说明本次提交的改内容。这样其他开发人员在查看提交历史时可以容易理解代码改的原因。 3. 分支管理:在进行代码改时,应该基于合适的分支进行操作,而不是直接在主分支上进行改。常见的分支管理策略包括主分支(用于稳定代码)和开发分支(用于新功能和bug修复)。 4. 合并代码:在将代码合并到主分支之前,应该先进行代码评审,并确保代码的质量和稳定性。代码评审可以帮助发现潜在的问题,并提高代码的整体质量。 5. 代码规范:在进行代码改时,应该遵循项目所采用的代码规范代码规范有助于提高代码的可读性和可维护性,并确保团队成员能够轻松理解和修改代码。 6. 冲突解决:在多人同时对同一文件进行改时,可能会发生冲突。在解决冲突时,应该仔细查看冲突的部分,并根据需要进行适当的修改。解决冲突后,应该进行测试以确保代码的正常运行。 7. 提交检查:在提交代码之前,应该进行必要的测试和代码质量检查。确保代码的正确性,并检查是否有任何潜在的问题。 总之,通过遵循以上规范,可以确保代码的质量和稳定性,并促进团队成员之间的良好协作。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值