站長資訊網本篇文章給大家帶來了關于Git的相關知識，其中主要介紹了Hooks使用說明，Git除了版本控制，還有一些其他的高級功能，其中之一就是Git Hooks，明面意思就是鉤子，可以類比于鉤子函數，希望對大家有幫助。
推薦學習：《Git學習教程》
Git 除了版本控制，還有一些其他的高級功能，其中之一就是Git Hooks，明面意思就是鉤子，可以類比于鉤子函數。簡單說就是Hook會在做某些事情的前后被鉤子鉤走去一些額外事情，那么這些額外事情我們可以用作于檢查、測試和部署等操作。
在 Git 中有許多的事件（commit、push 等等），每個事件也是對應了有不同的鉤子的（如 commit 前，commit 后），那么我們就可以在這些鉤子這里配置一些自己需要執行的操作來實現各種各樣的需求。
Git Hooks 介紹
Git hooks 是 Git 在事件之前或之后執行的腳本, 用于控制 git 工作的流程。Git hooks 腳本對于我們提交code review 之前識別一些簡單的問題很有用。 我們在每次提交代碼時都會觸發這些 hooks，以自動指出代碼中的問題，例如缺少分號，尾隨空白和調試語句。通過在code review 之前指出這些問題，代碼審閱者可以專注于代碼結構和功能的更改，而不需要浪費時間來審查這些格式問題。
Git hooks 分為客戶端鉤子和服務端鉤子。客戶端鉤子由諸如提交和合并這樣的操作所調用，而服務器端鉤子作用于諸如接收被推送的提交這樣的聯網操作。
客戶端鉤子：pre-commit、prepare-commit-msg、commit-msg、post-commit等，主要用于控制客戶端 git 的提交和合并這樣的操作。
服務端鉤子：pre-receive、post-receive、update，主要在服務端接收提交對象時、推送到服務器之前調用。
- pre-commit: Check the commit message for spelling errors.
- pre-receive: Enforce project coding standards.
- post-commit: Email/SMS team members of a new commit.
- post-receive: Push the code to production.
Git hooks 如何工作
Git Hooks 就是在.git/hooks文件下，保存了一些 shell 腳本，然后在對應的鉤子中執行這些腳本就行了。比如下圖中，這是一個還沒有配置 Git Hooks 的倉庫，默認會有很.sample結尾的文件，這些都是示例文件
例如打開pre-commit.sample文件看一下其中的內容，意思是一個示例鉤子腳本，用于驗證將要提交的內容，由沒有參數的“git commit”調用，如果鉤子想要停止提交，那么它應該在發出適當的消息后以非零狀態退出。這個腳本默認是不生效的，如果要生效，把文件名改為pre-commit即可。pre-commit這個鉤子是在git commit命令執行之前觸發。
Git 支持的所有鉤子見下表（加粗的為常用鉤子）：
自定義使用方法
1. 添加命名相同的腳本文件
任何正確命名的可執行腳本都可以正常使用 ，也可以用Ruby或Python，或其他腳本語言。如下我們編寫一個與prepare-commit-msg相同命名的python腳本即可，注意第一行改成了python解釋器的路徑。
#!/usr/bin/env python import sys, os commit_msg_filepath = sys.argv[1] with open(commit_msg_filepath, 'w') as f: f.write("# Please include a useful commit message!")
此外，這里用sys.argv[1]而不是$1來獲取第一個參數。這個特性非常強大，因為你可以用任何你喜歡的語言來編寫Git鉤子。
2. 直接修改sample文件
使用shell 這里嘗試寫一個簡單的鉤子，安裝一個prepare-commit-msg鉤子。去掉腳本的.sample拓展名，在文件中加上下面這兩行：
#!/bin/sh echo "# Please include a useful commit message!" > $1
接下來你每次運行git commit時，你會看到默認的提交信息都被替換了。
內置的樣例腳本是非常有用的參考資料，因為每個鉤子傳入的參數都有非常詳細的說明（不同鉤子不一樣）。
3. 鏈接自定義文件
因為hook文件其實就是個腳本文件，我們可以寫一個腳本文件到項目被git管理的任意目錄里即可，只要在.git/hooks/里的默認腳本文件中，執行我們外部的這個文件即可。
- 自定義腳本文件：項目根目錄
/githooks/commit-msg-impl.py
#!/usr/bin/env python import sys, os, re from subprocess import check_output # 收集參數，第一個參數是commit的信息的文件 commit_msg_filepath = sys.argv[1] # 打開commit提交消息的文件，檢測消息是否以指定格式開頭的，不是則異常退出，終止這次commit消息的提交 with open(commit_msg_filepath, 'r') as f: content = f.read() if not content.startswith("xxxx"): print "commit-msg: ERROR! The commit message must start with xxxx" sys.exit(1) - 默認hooks文件：.git/hooks/commit-msg #!/bin/bash GIT_ROOT="$(git rev-parse --show-toplevel)" FILE_NAME=$GIT_ROOT/githooks/commit-msg-impl.py if [ -f "$FILE_NAME" ]; then source $FILE_NAME fi
Husky 配置
從上面的介紹中，我們知道 Git Hook 保存在 .git 文件夾中，Git 是一個多人協作工具，那按理說 Git 倉庫中的所有文件都應該被跟蹤并且上傳至遠程倉庫的。但有個例外，.git文件夾不會，這就導致一個問題，我們在本地配置好 Git Hook 后，怎么分享給其他小伙伴兒呢？這時候，就輪到 Husky 出場了。
Husky 的原理是讓我們在項目根目錄中寫一個配置文件，然后在安裝 Husky的時候把配置文件和 Git Hook 關聯起來，這樣我們就能在團隊中使用 Git Hook 了。
第一步
使用 npm 初始化你的項目（如果項目已有 package.json，請跳至第二步）
npm init -y
第二步
安裝 Husky
// 注意 Node.js 版本要 >=10 npm install husky -D
第三步
書寫配置文件，4.2.5 版本的 Husky 共支持以下幾種格式的配置文件：
- .huskyrc
- .huskyrc.json
- .huskyrc.yaml
- .huskyrc.yml
- .huskyrc.js
- husky.config.js
個人習慣，這里我采用的是.huskyrc，在其中書寫 json 格式的配置，如下：
{ "hooks": { "pre-commit": "git restore -W -S dist examples/dist" } }
是不是很簡單，我們來解讀一下這個配置文件。hooks這個對象中，key 就是鉤子名，而 value 就是需要執行的命令。上面這個配置的含義就是，在每次執行 git commit之前，都會把dist和examples/dit目錄下的修改回滾，即不想這個目錄的文件被上傳。
上面我們只寫了一條命令，如果想執行兩條命令怎么辦呢？比如我還想在git commit之前用 EsLint 檢查一下代碼質量，我們可以像下面這樣寫：
{ "hooks": { "pre-commit": "git restore -W -S dist examples/dist && eslint ." } }
是的，就是這么簡單。如果 EsLint 檢測不通過，那么git commit是會被阻止的，就不用擔心"垃圾代碼"被提交到線上倉庫了。
Husky 注意事項
Husky 讓我們可以很方便的配置 Git Hooks，同時，也提供了一些實用方便的小技巧以及一些我們需要注意的點
不支持的鉤子
Husky 不支持服務端 Git 的鉤子：
- pre-receive
- update
- post-receive
跳過所有鉤子
有時你可能不想運行鉤子，那么可以像下面這樣跳過：
HUSKY_SKIP_HOOKS=1 git rebase ...
禁用自動安裝
如果你不想 Husky 為你自動安裝鉤子（比如 clone 了一個第三方的庫，想要自己開發時），可以這樣做：
HUSKY_SKIP_INSTALL=1 npm install
推薦學習：《Git教程》
