在git hooks的使用中,其實除了原生的方式外有個更方便的工具已經出來。

那有關於什麼是git hooks可以看我上禮拜寫的文章。
初探Git Hooks,優化Git工作流 | Vic’s Blog

在這邊簡單來說,git hooks 是每次 Git 存儲庫中發生特定事件時自動運行的腳本。

我想要做git的特定事件,像是pushmergecommit的執行前後,想做一些事情比如檢查,那就得靠git hooks的幫忙。

但那卻不是一件容易的事情,對很多人來說連找出.git隱藏檔都是困難的事情,更不用說自己寫腳本。

而husky就是為此而生,它讓操作git hooks變的更加簡單。

在Git專案中使用husky统一管理hooks,變成不難上手,性價比很高的一件事情。

這篇不會講解husky內部究竟是怎麼實現的,原始碼的解析,會著重在如何使用,以及理解為什麼需要有這個工具上,但研究的時候有幾篇提到這個部分,連結也會放在參考連結。

官網的安裝及使用說明得非常清楚,連結已放在最下面的參考資料,這邊我紀錄的是我自己比較偏好的方式,我選擇Automatic(自動)的安裝方式,這也是官網所推薦,接著我會選擇裡面其中的npm方式,其實還有Yarnpnpm,也都不錯,可以試試看。

1
2
3
4
5
6
7
8
9
// 安裝
npx husky-init && npm install

// 刪除
npm uninstall husky && git config --unset core.hooksPath

// 添加hook
npx husky add .husky/commit-msg 'npx --no -- commitlint --edit "$1"'

husky-init的這個指令可以理解成快速化初始husky所需項目的一次性懶人包。


它會加上 Husky 的相依並在 prepare 中加上 husky install ,這樣一來在 npm install 運行時就會執行 Husky 的安裝程序。

這也是剛剛安裝時後面還得補上npm install的原因。

安裝完後husky

如果是使用Automatic(自動)的安裝方式,那安裝完後,就會有一個預設初始的pre-commit可以來做使用。

pre-commit就是在git commit執行之前可以做的腳本,裡面一開始只會有npm test而已,可以在自己改掉。

簡單來說,專案就會多出一個叫做husky的資料夾,裡面可以看到pre-commithook(腳本),可以直接修改這邊做操作。

如果要添加hook的話,就直接husky add就好,上面有打示範的指令,跟原生git hooks不一樣,不會一開始就把所有存在的hooks都列出來,所以假如不知道自己需要的那個hooks是什麼可以需要查一下。

使用情境

那用預設的pre-commit來說,在git commit執行之前所運行的腳本,我所想得到的幾種運用:

  1. 使用eslint,做git commit執行前專案中語法的檢查。
  2. 使用prettier,做git commit執行前專案中程式碼格式的檢查。
  3. 使用commitlint,做git commit執行前commit訊息的檢查。

commitlint很酷,使用它就等於commit訊息有了統一的規範,要注意,第三點不在pre-commit的管轄中,應該要放在commit-msg裡面。

commitlint的話,腳本的部分如何搭配husky的話,也不用自己寫,直接照著官網做就ok了,它會有一個預設的通用規則,然後還可以照著自己想要的rules去新增。

通用的規則就會像是每個commit訊息都得要有個type等等,比如說:

1
feat(blog): add vic blog

官網連結:conventional-changelog/commitlint: 📓 Lint commit messages

那最後來演示如果是eslint,怎麼使用husky。

這個部分用四個我做練習的圖片來介紹。

第一步:

第二步:

第三步:

最後步:

總結

主要兩個地方做優化

  1. 易用性
  2. 可制定性 => 更方便,更客製

Husky 通過很簡單的方式,就能夠在專案中添加 Git Hooks,而不需要手動撰寫腳本,直接就拉低了整體使用門檻。

一直以來,Git Hooks 必須保存在 .git/hooks 目錄中,這使得它們難以在團隊中共享,隱藏檔無法被追蹤不能推到遠端,但Husky就不用那麼麻煩,因為已經變成了在.husky/hooks目錄裡面。

參考資料