北京
每個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.
