每個Git倉庫都自帶一個隱藏超能力:.git/hooks/ 文件夾。你只需要丟一個可執(zhí)行腳本進去,Git就會自動在提交前、推送前或合并前運行它——這就是原生的“提交衛(wèi)士”。可問題來了:這個文件夾不受版本控制,你費半天勁寫好的鉤子,隊友的機器上什么都沒有。所有所謂“Git鉤子管理器”要解決的,就這一件事。
dart_husky 的解法毫不花哨:沒有守護進程,沒有后臺常駐服務,整套機制只靠一個配置文件、一個Dart二進制和幾個薄薄的代理腳本就能運轉(zhuǎn)。下面拆開看,這玩意兒怎么做到“插一針就能卡住所有commit”。
![]()
1. 配置文件說了算
在項目根目錄放一份YAML文件,聲明“什么時候該跑什么命令”。一套dart_husky配置,無非就是告訴系統(tǒng):pre-commit 時跑代碼格式化,commit-msg 時檢查提交信息是否符合規(guī)范。一個解析器負責把這堆YAML讀成結(jié)構(gòu)化的模型對象,后面所有步驟都只認這些對象,不碰裸YAML。
2. 命令行把東西串起來
dart_husky 的CLI干兩件事:安裝和運行。跑安裝命令時,它往 .git/hooks/ 里寫入極簡的委托腳本——這些腳本不干正經(jīng)活,只負責轉(zhuǎn)發(fā)給真正的Dart執(zhí)行器。因為 .git/hooks/ 目錄本身不受版本控制,所以每次隊友拉代碼后都得執(zhí)行一次安裝,但這一步只要自動掛到依賴安裝流程里就行。
3. 代理腳本,真正的“鉤子”
每次Git觸發(fā)鉤子事件,實際執(zhí)行的是那些小到只有幾行的shell腳本。它們把控制權(quán)交給一個單一Dart二進制,這個二進制負責去讀YAML配置里對應階段的命令,再按順序執(zhí)行。這種設計的好處是:一個二進制處理所有鉤子類型,不用為每個階段維護獨立腳本。
4. 運行器:不執(zhí)行則已,執(zhí)行就卡住一切
當 git commit 被觸發(fā),Git運行代理腳本 → 腳本調(diào)用Dart運行器 → 運行器按配置調(diào)用實際命令(比如dart format、flutter test)。一旦任何一條命令返回非零退出碼,提交立刻被攔下——整個過程沒有后臺服務,完全借Git自身的hook機制驅(qū)動。
5. 提交信息驗證器
針對 commit-msg 階段,dart_husky 內(nèi)置了 Conventional Commits 規(guī)范的校驗。解析器把提交消息拆成類型、作用域和描述,不符合“feat: 新功能”或“fix: 修bug”格式的直接拒絕。這讓團隊堅持了一致的提交歷史,而不再靠人工審核。
整套架構(gòu)就這么簡單:YAML定義規(guī)則,解析器轉(zhuǎn)成模型,CLI安裝薄腳本,運行器執(zhí)行真正命令,驗證器攔住不規(guī)范消息。沒有后臺守護,不干擾日常Git操作;你用的還是原汁原味的Git鉤子,只是不再需要讓隊友手動復制腳本了。如果你在開發(fā)Dart或Flutter應用,dart_husky已在pub.dev可用。覺得順手,給GitHub點個星,算是對這種“只解決一個問題”工具的鼓勵。
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.