• home > tools > versionControl > git >

    前端git项目commit规范化之钩子:husky的使用与常见错误分析

    Author:zhoulujun Date:

    团队人一多,提交一多,还是要对备注加以区分,好快速找到变更点。这时候就需要对每次提交,需要输入message,对提交的备注进行规范化处理

    团队人一多,提交一多,还是要对备注加以区分,好快速找到变更点。这时候就需要对每次提交,需要输入message,对提交的备注进行规范化处理

    • 代码规范落地难:归根结底在于需要工具去强行保证代码必须经过代码开发规范的扫描;

    • 低质量代码带入线上应用:最好的方式本地进行commit的时候,最起码需要保证当前代码能够满足团队制定的开发规范,如果不通过,commit都无法成功,这样能够从最源头保证代码质量问题;

    • 代码格式难统一:需要一种工具强制保证团队内代码的格式是一致;

    • 代码质量文化难落地:通过引入代码质量工具,在开发过程中能够时刻对自身代码质量进行约束,逐渐培养自身对代码质量有“洁癖”的开发观念,同时也会成为团队乃至自身对质量文化落地的一个抓手。

    要想防患于未然,防止将存在潜在问题的代码带到线上环境,最好的办法是在本地提交代码时就能够扫描出潜在的错误,并强制将其修改后才能提交,这样就不会将问题代码携带到线上,就能保证线上代码至少不会存在低级的程序错误。

    Git 提交备注规范

    • feat: 新增 feature

    • fix: 修复 bug

    • docs: 仅仅修改了文档,比如 README, CHANGELOG, CONTRIBUTE等等

    • style: 仅仅修改了空格、格式缩进、逗号等等,不改变代码逻辑

    • refactor: 代码重构,没有加新功能或者修复 bug

    • perf: 优化相关,比如提升性能、体验

    • test: 测试用例,包括单元测试、集成测试等

    • chore: 改变构建流程、或者增加依赖库、工具等

    • revert: 回滚到上一个版本

    Git分支与版本发布规范

    • 基本原则:master为保护分支,不直接在master上进行代码修改和提交。

      开发日常需求或者项目时,从master分支上checkout一个feature分支进行开发或者bugfix分支进行bug修复,功能测试完毕并且项目发布上线后,将feature分支合并到主干master,并且打Tag发布,最后删除开发分支。分支命名规范:

    • 分支版本命名规则:分支类型 _ 分支发布时间 _ 分支功能。比如:feature_20170401_fairy_flower

      • 时间使用年月日进行命名,不足2位补0

      • 分支功能命名使用snake case命名法,即下划线命名。

      • Tag包括3位版本,前缀使用v。比如v1.2.31。Tag命名规范:

      • 新功能开发使用第2位版本号,bug修复使用第3位版本号

      • 核心基础库或者Node中间价可以在大版本发布请使用灰度版本号,在版本后面加上后缀,用中划线分隔。alpha或者belta后面加上次数,即第几次alpha:v2.0.0-alpha.1、v2.0.0-belta.1

    • 分支类型包括:feature、 bugfix、refactor三种类型,即新功能开发、bug修复和代码重构

    版本正式发布前需要生成changelog文档,然后再发布上线

    这些规范讲出来,但是大家不一定完全遵守。所以,需要对每次提交加钩子,镜像验证

    Commit message 格式

    每次提交,Commit message 都包括三个部分:header,body,footer

    git 提交校验配置

    主要借助于:https://github.com/typicode/husky#readme

    细节方面可以参看:《husky介绍及使用

    需要增加配置

    {
       "scripts": {
        "precommit": "lint-staged"
      },
      "devDependencies": {
        "babel-eslint": "^8.1.1",
        "eslint": "^5.0.0",
        "eslint-config-ali": "^2.0.1",
        "eslint-plugin-import": "^2.6.0",
        "eslint-plugin-react": "^7.1.0",
        "husky": "^0.14.2",
        "lint-staged": "^4.0.0",
        "prettier":"^1.16.4",
        
        "eslint-plugin-prettier":"^3.0.1",
        "eslint-config-prettier":"^4.0.0"
        "husky": "^4.3.0",
        "@commitlint/cli": "^11.0.0",
        "@commitlint/config-conventional": "^11.0.0",
      },
      "husky": {
        "hooks": {
            "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
          }
      },
      "lint-staged": {
        "*.{js,jsx,ts,tsx}": [
          "prettier --write",
          "eslint --fix",
          "git add"
        ],
        "*.{html,css,less,ejs,json}": [
          "prettier --write",
          "git add"
        ]
      }
    }

    增加.eslintrc.js扫描规则:

    module.exports = {
      "extends": ["prettier", "plugin:prettier/recommended"],
      "parser": "babel-eslint",
      "rules": {
        "prettier/prettier": "error",
        "strict": "off",
        "no-console": "off",
        "import/no-dynamic-require": "off",
        "global-require": "off",
        "require-yield": "off",
      },
      "plugins": ["prettier"],
      "globals": {
        "React": "readable"
      }};

    增加.prettierrc.js文件,用于在扫描通过后格式化代码(该步骤可选,如果不引入prettier的话,相应的在package和eslintrc中去除掉相应配置即可)

    module.exports = {
      printWidth: 80,
      semi: true,
      singleQuote: true,
      trailingComma: 'none',
      bracketSpacing: true,
      jsxBracketSameLine: false,
      arrowParens: 'avoid',
      requirePragma: false,
      proseWrap: 'preserve'
    };

    加了钩子后提交:git commit -m "XXX",发现提交不了,报错

    commit提交的时候报错

    下面是常见的错误

    zsh: no matches found

    因为没有此配置:因为zsh缺省情况下始终自己解释这个 *.h,而不会传递给 find 来解释。

    1. vi ~/.zshrc

    2. 插入(i) :etopt no_nomatch

    3. 保存退出(ese,qw)

    4. 执行:source .zshrc

    husky > pre-commit hook failed (add --no-verify to bypass)

    提交代码的时候,pre-commit(客户端)钩子,它会在Git键入提交信息前运行做代码风格检查。如果代码不符合相应规则,则报错,而它的检测规则就是根据.git/hooks/pre-commit文件里面的相关定义。

    解决办法:

    • 进入项目的.git文件夹(文件夹默认隐藏,可先设置显示或者命令ls查找),再进入hooks文件夹,删除pre-commit文件,重新git commit -m 'xxx' git push即可。

    • 将git commit -m "XXX" 改为 git commit --no-verify -m "XXX"


    参考文章:

    eslint+husky+prettier+lint-staged提升前端应用质量 :https://www.jianshu.com/p/bea740c966e9

    GitHook 工具 —— husky介绍及使用 https://www.cnblogs.com/jiaoshou/p/12222665.html




    转载本站文章《前端git项目commit规范化之钩子:husky的使用与常见错误分析》,
    请注明出处:https://www.zhoulujun.cn/html/tools/VCS/git/8582.html