項目git commit時卡主不良程式碼：husky讓Git檢查程式碼規範化工作

看完 《前端規範之Git工作流規範（Husky + Commitlint + Lint-staged） //www.cnblogs.com/Yellow-ice/p/15349873.html》，再次修改本文

 

團隊人一多，提交一多，還是要對備註加以區分，好快速找到變更點。這時候就需要對每次提交，需要輸入message，對提交的備註進行規範化處理

  • 程式碼規範落地難：歸根結底在於需要工具去強行保證程式碼必須經過程式碼開發規範的掃描；

  • 低品質程式碼帶入線上應用：最好的方式本地進行commit的時候，最起碼需要保證當前程式碼能夠滿足團隊制定的開發規範，如果不通過，commit都無法成功，這樣能夠從最源頭保證程式碼品質問題；

  • 程式碼格式難統一：需要一種工具強制保證團隊內程式碼的格式是一致；

  • 程式碼品質文化難落地：通過引入程式碼品質工具，在開發過程中能夠時刻對自身程式碼品質進行約束，逐漸培養自身對程式碼品質有「潔癖」的開發觀念，同時也會成為團隊乃至自身對品質文化落地的一個抓手。

要想防患於未然，防止將存在潛在問題的程式碼帶到線上環境，最好的辦法是在本地提交程式碼時就能夠掃描出潛在的錯誤，並強制將其修改後才能提交，這樣就不會將問題程式碼攜帶到線上，就能保證線上程式碼至少不會存在低級的程式錯誤。

有些同學可能會把ESLint、Stylelint或Commitizen提示的錯誤忽視不見，直接將程式碼提交到程式碼倉庫中。這樣做的話，那麼其他同學在pull程式碼並diff程式碼時可能會出現大段程式碼標紅，同時在進行CI時又可能因為程式碼風格或規範問題被打回重改。

如何讓大家在提交程式碼時需要確保本地的程式碼或Commit Message已經通過檢查才能夠push到程式碼倉庫，從而更好的保障程式碼品質呢？

可以用 Husky + Commintlint + Lint-staged打造規範的Git檢查工作流，確保我們的程式碼只有符合規範才能提交到程式碼倉庫。

什麼是git hook

git hook，也就是常說的Git鉤子。

Git能在特定的重要動作發生時觸發自定義腳本。有兩組這樣的鉤子：客戶端的和伺服器端的。

  • 客戶端鉤子由諸如提交和合併這樣的操作所調用

  • 伺服器端鉤子作用於諸如接收被推送的提交這樣的聯網操作

客戶端鉤子我們可能用的比較多，客戶端鉤子通常包括了提交工作流鉤子、電子郵件工作流鉤子和其它鉤子。這些鉤子通常存儲在項目的.git/hooks目錄下，我們需要關注的主要是提交工作流鉤子。提交工作流鉤子主要包括了以下四種：

  • pre-commit：該鉤子在鍵入提交資訊前運行。 它用於檢查即將提交的快照。如果該鉤子以非零值退出，Git 將放棄此次提交，你可以利用該鉤子，來檢查程式碼風格是否一致。

  • prepare-commit-msg：該鉤子在啟動提交資訊編輯器之前，默認資訊被創建之後運行。 它允許你編輯提交者所看到的默認資訊。

  • commit-msg：該鉤子接收一個參數，此參數存有當前提交資訊的臨時文件的路徑。 如果該鉤子腳本以非零值退出，Git 將放棄提交，因此，可以用來在提交通過前驗證項目狀態或提交資訊。

  • post-commit：該鉤子一般用於通知之類的事情。

在上面的鉤子中，我們需要關注pre-commit和commit-msg鉤子。

Commit message 格式

每次提交，Commit message 都包括三個部分：header，body，footer

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文檔，然後再發布上線

這些規範講出來，但是大家不一定完全遵守。所以，需要對每次提交加鉤子，鏡像驗證

Husky

husky是常見的git hook工具，使用husky可以掛載Git鉤子，當我們本地進行git commit或git push等操作前，能夠執行其它一些操作，比如進行ESLint檢查，如果不通過，就不允許commit或push。

具體參看：//typicode.github.io/husky/#/

husky 運行：

並在package.josn里添加如下命令

"prepare": "husky install"

運行完會生成.husky文件夾，在.husky文件夾下有一個pre-commit，這個文件是用來定義git commit之前應該執行什麼命令，默認內容如下

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"

#npm test
#自定義命令，手動添加
npm run lint:eslint
npm run lint:stylelint

你可以進行自定義命令，來進行提交前的校驗

lint-staged

默認情況下上面的命令會對所有的程式碼進行校驗，這無疑是非常浪費時間的。這時候我們需要藉助 lint-staged

來對暫存的 git 文件運行校驗

具體查看：//www.npmjs.com/package/lint-staged

在package.json 里添加如下程式碼

{
  "lint-staged": {
    "src/**/*.{less,scss,css}": [
      "stylelint --fix --syntax=less",
      "git add ."
    ],
    "src/**/*.{js,ts,tsx,vue}": [
      "eslint ./src  --ext .js,.tsx,.ts,.vue --cache --fix",
      "git add ."
    ]
  },
  "scripts": {
    "lint": "eslint --fix src",
    "lint:style": "stylelint --fix ./**/*.{scss,css,vue} --custom-syntax",
    "prepare": "husky install"
  },
  "devDependencies": {
    "@blueking/eslint-config-bk": "^2.1.0-beta.6",
    "@blueking/stylelint-config-bk": "^2.0.0",
    "@commitlint/cli": "^17.0.3",
    "@commitlint/config-conventional": "^17.0.3",
    "bk-vision-cli": "^4.0.4",
    "husky": "^8.0.1",
    "lint-staged": "^13.0.3",
  }
}

創建 commitlint.config.js

在根目錄下創建 . commitlint.config.js

module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [
      2,
      'always',
      [
        'feature',
        'feat',
        'bug',
        'fix',
        'bugfix',
        'refactor',
        'perf',
        'style',
        'test',
        'docs',
        'info',
        'format',
        'merge',
        'depend',
        'chore',
        'del',
      ],
    ],
    'subject-valid': [2, 'always'],
  },
  plugins: [
    {
      rules: {
        'subject-valid'({ subject }) {
          console.log('it is a subject', subject);
          return [
            /^[\s\S]+?(issue\s+#\d+)$/i.test(subject),
            'commit-msg should end with (issue #{issueId})',
          ];
        },
      },
    },
  ],
};

工程結構如下：

WX20220711-210912@2x.jpg

eslint

增加.eslintrc.js掃描規則：(.eslintrc.js)

module.exports = {
  root: true,
  extends: ['@blueking/eslint-config-bk/tsvue3'],
  rules: {
    'no-param-reassign': 0,
    '@typescript-eslint/naming-convention': 0
  }
};

style-lint

增加style-lint 規則(.stylelintrc.js)

module.exports = {
  defaultSeverity: 'error',
  extends: ['@blueking/stylelint-config-bk']
}

prettierr

增加.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提升前端應用品質 ：//www.jianshu.com/p/bea740c966e9

husky介紹及使用 //www.cnblogs.com/jiaoshou/p/12222665.html

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

前端規範之Git工作流規範 Husky + lint-staged //blog.csdn.net/weixin_41897680/article/details/125233875

 

 

轉載本站文章《項目git commit時卡主不良程式碼：husky讓Git檢查程式碼規範化工作》,
請註明出處：//www.zhoulujun.cn/html/tools/VCS/git/8582.html

Tags:

VirMach 便宜 VPS

QNews

QNews