golangci-lint를 로컬에서 사용하는 솔루션

코드 검사는 왜 필요한가요?

일반적으로 코드 검사는 다음 세 가지 이유로 중요합니다.

1. 낮은 수준의 버그 방지: 일부 일반적인 코드 문제는 컴파일 또는 실행 전에 시간 내에 발견되지 않으면 코드의 문법 문제로 인해 컴파일 또는 런타임이 직접 발생합니다. 오류는 개발 효율성과 코드 품질에 영향을 미칩니다.

2. 통합된 코딩 습관: 모든 팀이나 개인은 나중에 유지 관리하고 읽을 수 있도록 일부 코딩 사양이나 코딩 습관을 가지고 있습니다. 특정 형식 사양

3. 온라인 코드 품질 보장: 버전 관리에서는 코드가 최종 버전 요구 사항을 충족하는지 확인하기 위해 제출 또는 릴리스 전에 일부 코드 검사 작업을 자동으로 수행해야 합니다.

golangci-lint는 golang이 지원하는 최고의 코드 검사 도구이며 golang 오픈 소스 라이브러리에서 널리 사용됩니다. 이는 프로젝트의 더 나은 개발과 향후 더 나은 유지 관리를 위해 우리도 시도해 볼 수 있음을 보여줍니다. 그것을 소개합니다. golangci-lint作为 golang 支持最好的代码检查工具，而且在golang开源库中，有着大量的使用，由此可以说明为了项目更好的进行开发，和后期更好的维护，我们也可以尝试着引入它。

尝试使用 goalngci-lint 的问题

我们再日常的开发过程中，习惯的行为是：code -> git add -> git commit -> git push 一条龙服务。

1. 手动执行模式：

那么这个时候需要在 git commit 之前检查我们的代码是否已经符合一定的规则，就需要手动执行 golangci-lint run ./... ，或者在 git push

🎜🎜goalngci-lint 사용에 대한 질문🎜🎜우리의 일상적인 개발 과정에서 우리의 관례적인 행동은 다음과 같습니다: code -> git add -> git push 원스톱 서비스. 🎜

🎜🎜1 수동 실행 모드: 🎜 🎜

🎜 그런 다음 이때 git commit 코드가 특정 규칙을 준수했는지 확인하기 전에 수동으로 실행해야 합니다golangci-lint run ./... 또는 git push는 이전에 코드 검토를 위한 것입니다. 커밋과 푸시는 일상적인 작업이므로 자주 수행될 가능성이 높으며 이 수동 방법은 다소 번거롭습니다. 사용하는 과정에서 어떤 일로 인해 잊어버리거나 직접 실행하지 못하여 번거로움을 느끼고 자신의 코드에 대해 완전한 자신감을 갖게 될 수도 있습니다. 그래서 전체적으로 사용해본 후에도 여전히 매우 매끄럽지 않다는 것을 아셔야 합니다. 🎜

2.gitlab 러너 모드:

이 솔루션을 생각한 이유는 아마도 서버 코드 검사를 사용하는 오픈 소스 라이브러리를 너무 많이 봤기 때문일 것입니다(비록 PR일지라도)

를 통해 gitlab을 구축하세요. docker 를 작성하고 튜토리얼을 통해 러너를 구성하는데 이틀이 걸렸습니다. 하지만 gitlab의 ci 구성과 러너의 작업 구성, 일부 도구 설치를 배워야 했지만 결과가 만족스럽지 않을 수 있습니다.

서버 점검 결과가 gitlab에 있다고 생각하면 우리 개발은 기본적으로 (처음 코드를 가져올 때) gitlab에 가지 않는데 어떻게 이 오류 메시지가 해당자에게 전달될 수 있겠습니까? 아니면 여러 사람이 함수를 작성하는 경우 오류를 할당하는 방법은 무엇입니까? 서버 확인을 사용하는 이 솔루션은 통과하는 데 2일이 걸렸습니다.

3. 로컬 사전 커밋

서버 확인이 작동하지 않으므로 코드를 제출하기 전에 스크립트 확인을 수행합니다. 그러면 강제로 제출되지 않습니다. 귀하의 오류를 처리하기 위해. 하하하(메커니즘)는 강제로 제출할 수 있다는 것을 알려주지 않습니다(주의해서 사용하세요).

이것은 로컬 사전 커밋 스크립트 작성을 시작합니다. 나는 온라인에서 정보를 검색하고 내 필요에 따라 사전 커밋 스크립트를 작성했습니다. 주로 코드fmt 및 코드<code style="font-size: 14px;overflow-wrap: break-word;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb (30, 107, 184);배경색: rgba(27, 31, 35, 0.05);글꼴 계열: " operator mono consolas monaco menlo monospace break-all> golangci-lint 확인. 이번에는 꼭 성공할 거라고 생각했어요! fmt和代码golangci-lint 检查。心想这次一定能成！

这时，脚本写好了，但是改怎么上传到服务器呢，由于.git 文件夹作为默认不可上传到服务器，只有写一个 init.sh 的脚本来上传服务器了，所有开发人员在第一次获取项目的时候只需要执行一下，本地的配置就好了，这就简单很多了。

试着跑了一下：

。。。结果不得行。此处文字已经不能表达我的心情了。

经过一系列的操作后，发现golangci-lint

이제 스크립트는 작성했는데 어떻게 서버에 업로드할 수 있나요? .git 폴더는 기본적으로 서버에 업로드할 수 없기 때문에 init.sh 스크립트만 작성해서 서버에 업로드하면 됩니다. 모든 개발자는 처음으로 이를 서버에 업로드해야 하며, 프로젝트를 가져올 때 로컬에서 실행하고 구성하기만 하면 훨씬 간단합니다.

실행해 보세요:

1. . . . 결과가 작동하지 않습니다. 여기 있는 단어로는 내 감정을 표현할 수 없습니다.

   일련의 작업 후에 golangci-lint는 개별 파일 검사를 지원하지 않습니다.

   🎜제 스크립트 검사 원칙은 다음과 같습니다. 🎜🎜🎜🎜🎜현재 커밋에서 수정된 모든 go 파일을 필터링합니다🎜

2. 각 파일에 대해 한 번 실행golangci-lint xxx.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

이건 당황스럽습니다. 원래는 스크립트를 사용하여 모든 파일이 있는 폴더를 필터링하고 폴더에서만 실행하려고 했습니다. 왜냐하면 이 스크립트를 작성하는 것이 나에게는 약간 복잡하기 때문입니다. 어려운) ). 물론 또 다른 문제가 있습니다. golangci-lint 실행 과정은 시간이 오래 걸립니다. 각 커밋마다 1분씩 기다려야 한다고는 말할 수 없습니다. 이로 인해 위장 낚시 시간이 늘어납니다.

4. 로컬 사전 커밋 + 사전 푸시

많은 고민 끝에 마침내 우리에게 비교적 적합한 솔루션을 찾았습니다.

viainit.sh 기본값 수정git Hook 위치를 githooks 폴더, 특정 You 작업을 통해 스크립트 내용을 볼 수 있습니다. 스크립트가 매우 명확하다고 생각합니다.

viapre-commit fmt 및 import 검사와 자동 서식 제공 일부 작업을 방지하기 위해 추가됨 자신을 포맷하는 것을 잊어버린 곳.

viapre-push 프로젝트가 푸시 가능한 상태로 푸시되었는지 확인 서버를 사용합니다. Push는 그다지 빈번하지 않기 때문에 이때 전체 프로젝트에 대한 점검이 사용됩니다.

🎜🎜🎜🎜🎜🎜

위 내용은 golangci-lint를 로컬에서 사용하는 솔루션의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!