我们为什么需要进行代码检查？
通常，代码检查很重要，原因有三：
避免低级bug：一些常见代码问题，如果在编译或运行前不能及时发现，代码中的语法问题会直接导致编译或运行时错误，影响开发效率和代码质量；
统一代码习惯：每一个团队或个人都会有一些代码规范或者代码习惯，为了便于后期维护和阅读，我们编写的代码也需要符合一定的格式规范；
保证线上代码质量：在版本管理中，我们需要在提交或发布之前自动执行一些代码检查工作，确保我们的代码符合最终版本要求。
golangci-lint作为 golang 支持最好的代码检查工具，而且在golang开源库中，有着大量的使用，由此可以说明为了项目更好的进行开发，和后期更好的维护，我们也可以尝试着引入它。
尝试使用 goalngci-lint 的问题
我们再日常的开发过程中，习惯的行为是：code -> git add -> git commit -> git push 一条龙服务。
1. 手动执行模式：
那么这个时候需要在 git commit 之前检查我们的代码是否已经符合一定的规则，就需要手动执行 golangci-lint run ./... ，或者在 git push 之前进行代码检查。由于我们的 commit 和 push 都是日常操作，大概率比较频繁，而这种手动的方式，多少有点繁琐了。而在这种使用过程中，由于一些事情，可能也会忘记，更或者直接就不执行，觉得麻烦并对自己的代码充满信心。所以整体使用下来，还是非常的emm， 你应该懂的，不顺手。
2. gitlab runner 模式：
想到这个方案的原因可能是，我看到太多的开源库都采用了服务器代码检查（虽然只是 pr）
通过 docker 搭建了一个 gitlab，并通过教程配置好了 runner，这花费了我2天时间，奈何我需要学习 gitlab 的 ci 配置，runner 的 job 配置，以及 一些工具的安装，但是结果可能多少不太得劲。
想到服务器检查的结果在gitlab上，我们开发基本上（第一次拉取代码）不会到 gitlab 上去，那么这个错误信息怎么投递到对应的人手里？或是多人写一个功能，这种又怎么去分配错误？这种采用服务器检查的方案被花费2天时间而pass掉。
3. 本地 pre-commit
既然服务器检查行不通，那么我在提交代码之前就进行脚本检查，有错误就不让提交，这就会强制你处理你的错误。哈哈哈（机制啊）不会告诉你可以强制提交（慎用啊）。
这就开始了本地 pre-commit 脚本的编写。通过网上查找资料并通过自己的需要编写好了一个 pre-commit 脚本。主要是代码fmt和代码golangci-lint 检查。心想这次一定能成！
这时，脚本写好了，但是改怎么上传到服务器呢，由于.git 文件夹作为默认不可上传到服务器，只有写一个 init.sh 的脚本来上传服务器了，所有开发人员在第一次获取项目的时候只需要执行一下，本地的配置就好了，这就简单很多了。
试着跑了一下：
。。。结果不得行。此处文字已经不能表达我的心情了。
经过一系列的操作后，发现golangci-lint 不支持对单个文件的检查。
而我脚本检查原理是这样：
筛选当前 commit 中修改的所有 go文件
每个文件都运行一次
golangci-lint run xxx.go
这就尴尬了；后面本来想通过脚本来过滤出所有文件所在的文件夹，只针对文件夹来跑，由于写这个脚本对于我来说有点复杂（不会这个难的）了。当然还有一个问题是 golangci-lint 的执行过程需要很长的时间，不能说每次commit都等个1分钟，这不就变相增加摸鱼时间了[/doge] 。
4. 本地 pre-commit + pre-push
经过多番折腾，终于诞生了一个相对前面方案，非常适合我们的一种方式。
通过 init.sh 修改默认git hook 位置到 我们创建的 githooks 文件夹，具体的操作可以查看脚本内容，我觉得脚本写的还是挺明确的。
通过 pre-commit 提供 fmt 和 import 的检查和自动格式化再自动添加，避免一些忘记自己格式化的操作。
通过pre-push来检查项目是否在可以使用的状态下推送到服务端。由于push不是那么频繁，所以这个时候采用的是整个项目的检查。
