通常，程式碼檢查很重要，原因有三：
#避免低階bug：一些常見程式碼問題，如果在編譯或執行前不能及時發現，程式碼中的語法問題會直接導致編譯或執行時間錯誤，影響開發效率和程式碼品質；
統一程式碼習慣：每個團隊或個人都會有一些程式碼規格或程式碼習慣，為了方便後期維護和閱讀，我們寫的程式碼也需要符合一定的格式規格；
保證線上程式碼品質：在版本管理中，我們需要在提交或發布之前自動執行一些程式碼檢查工作，確保我們的程式碼符合最終版本要求。
golangci-lint作為golang 支援最好的程式碼檢查工具，而且在golang開源程式庫中，有著大量的使用，由此可以說明為了專案更好的開發，和後期更好的維護，我們也可以嘗試引入它。
我們再日常的開發過程中，習慣的行為是：code -> git add -> git commit - > git push 一條龍服務。
那麼這個時候需要在git commit 之前檢查我們的程式碼是否已經符合一定的規則，就需要手動執行golangci-lint run ./... ，或在git push 之前進行程式碼檢查。由於我們的 commit 和 push 都是日常操作，大機率比較頻繁，而這種手動的方式，多少有點繁瑣了。而在這種使用過程中，由於一些事情，可能也會忘記，更或者直接就不執行，覺得麻煩並對自己的程式碼充滿信心。所以整體使用下來，還是非常的emm， 你該懂的，不順手。
#想到這個方案的原因可能是，我看到太多的開源程式庫都採用了伺服器程式碼檢查（雖然只是pr）
透過docker 建立了一個gitlab，並透過教學配置好了runner，這花了我2天時間，奈何我需要學習gitlab 的ci 配置，runner 的job 配置，以及一些工具的安裝，但是結果可能多少不太得勁。
想到伺服器檢查的結果在gitlab上，我們開發基本上（第一次拉取程式碼）不會到 gitlab 上去，那麼這個錯誤訊息怎麼投遞到對應的人手裡？或是多人寫一個功能，這種又怎麼去分配錯誤？這種採用伺服器檢查的方案被花費2天時間而pass掉。
#既然伺服器檢查行不通，那麼我在提交程式碼之前就進行腳本檢查，有錯誤就不讓提交，這就會強制你處理你的錯誤。哈哈哈（機制啊）不會告訴你可以強制提交（慎用啊）。
這就開始了本地 pre-commit 腳本的編寫。透過網路上尋找資料並透過自己的需求編寫好了一個 pre-commit 腳本。主要是代碼fmt和代碼golangci-lint 檢查。心想這次一定能成！
這時，腳本寫好了，但是改怎麼上傳到伺服器呢，由於.git 資料夾作為預設不可上傳到伺服器，只有寫一個init.sh 的腳本來上傳伺服器了，所有開發人員在第一次取得專案的時候只需要執行一下，本地的配置就好了，這就簡單很多了。
試著跑了一下：
。 。 。結果不得行。此處文字已經不能表達我的心情了。
經過一系列的操作後，發現golangci-lint 不支援單一檔案的檢查。
而我腳本檢查原理是這樣：
篩選目前 commit 中修改的所有 go檔案
每個檔案都執行一次golangci-lint run xxx.go
golangci-lint 的執行過程需要很長的時間，不能說每次commit都等個1分鐘，這不就變相增加摸魚時間了[/doge] 。
init.sh 修改預設git hook 位置到我們建立的githooks 資料夾，具體的操作可以查看腳本內容，我覺得腳本寫的還蠻明確的。
pre-commit 提供 fmt 和 import 的檢查和自動格式化再自動添加，避免一些忘記自己格式化的操作。
pre-push來檢查項目是否在可以使用的狀態下推送到服務端。由於push不是那麼頻繁，所以這個時候採用的是整個專案的檢查。
以上是在本地使用 golangci-lint 的方案的詳細內容。更多資訊請關注PHP中文網其他相關文章！
