{ "precommit": "lint-staged", "prepush": "ng test && ng build --prod"}在 precommit 時，我們配合 lint-staged 和 prettier 來進行代碼格式化：
"lint-staged": { "src/app/*.{css,scss}": [ "stylelint --syntax=scss", "prettier --parser --write", "git add" ], "{src,test}/**/*.ts": [ "prettier --write --single-quote", "git add" ] }事實上，使用 ng lint --fix 也是一個不錯的方式。
隨後，我們在 push 代碼之前，即 prepush，進行了測試及 Angular 的構建 production 的腳本。由於單元測試運行得相當的快，它可以在幾分鐘內完成，快速對問題做出響應。而不是等到持續集成出問題時，再去修復。
但是 Git 提高了這一種的種選項，也提供了一個 --no-verify 的參數。它可以讓開發者不需要進行上面的驗證，就能提交代碼。
我們往往無法阻止別人做這樣的事情，特別是當出現多個團隊協作的時候。
難以防範的危險提交
原本，我想將標題取為 “有風險的提交”，但是我覺得危險的提交更為可靠。
常見的有要去吃飯了、要下班了、要開會了等等，臨走前提交了一下代碼。功能可能本身沒有問題，但是它 block 後續的一系列行為。
當然了出現不可坑的因素，如地震、火災等的時候，就不需要考慮這些事情了。
只是有了這些規範和實踐，可以幫助我們開發出更穩定的 Web 應用。
結論
開發速度和質量，是一個難以平衡的天平。在不同的時間裡，我們應該做不同的技術決策。
如果您覺得喜歡 請動動小手 點下關注 謝謝您 前端小學生 期待與您 共同成長。
分享到:
閱讀更多 前端小學生 的文章
