在建立新的仓库时，为不同类型的代码选择合适对应的linter既费时又繁琐。有这么多的工具和配置可供选择，我们往往需要不止一种linter来覆盖我们使用的所有语言。GitHubSuperLinter的构建是出于GitHubServicesDevOps工程团队的需要，目的是使我们的文档和代码保持一致，同时改善整个公司的沟通和协作。现在我们正式开源它，这样每个人都可以使用和改进它！https://github.com/github/super-linterSuperLinter通过自动化解决了很多需求。它的功能包括：防止将损坏的代码上传到master分支；帮助建立多种语言的编码最佳实践；创建代码布局和格式的指南；自动化流程以帮助简化代码审查；在内部/向客户和合作伙伴交付更好、更清洁、更稳定的代码。1.这是什么？SuperLinter是打包到Docker容器中并由GitHubActions调用的源代码存储库。这样GitHub.com上的任何存储库都可以调用SuperLinter并从中受益。SuperLinter目前支持多种语言，未来会支持更多语言。有关支持的语言的详细信息，请参阅README.md。https://github.com/github/super-linter/blob/master/README.md2。工作机制设置仓库开始运行这个动作（Action）后，只要你打开一个pullrequest，仓库就会开始linting代码并通过StatusAPI返回。如果所有代码更改都成功通过，或者是否检测到任何错误，它会通知您它们在哪里以及它们是什么。然后开发人员可以返回到他们的分支，解决任何问题，并为这个开放的PR创建一个新的推送。届时，SuperLinter将再次运行并验证更新后的代码并重复该过程。您可以配置分支保护规则以添加“所有代码必须在合并前通过”的额外规则。SuperLinter有大量带有徽标和模板的自定义选项，您可以为自己的存储库进行调整。只需按照SuperLinter存储库和SuperLinterWiki上的详细说明进行操作。https://github.com/github/super-linter/wiki此工具对于将多种类型的代码和/或文档保存在一起的存储库（单体存储库）也很有用。3.默认规则在SuperLinter中标准化规则集是一项有趣的挑战，因为每个开发人员都以独特的方式进行编码。所以我们允许用户根据自己的仓库情况对linter使用任何规则。但是如果用户没有定义规则集，那么我们必须有一个默认标准。Ruby和Rails的规则集来自Rubygem：rubocop-github，并遵循我们在GitHub.com使用的相同规则集和版本控制策略。https://github.com/github/rubocop-github对于其他语言，我们在安装linter时指定默认，例如：coffeelint或yamllint。至于其余的，我们试图找到一个很好的平衡——简单的基础和可以帮助建立一些最佳实践，例如：Markdownlint或pylint。https://github.com/clutchski/coffeelinthttps://github.com/adrienverge/yamllint这样做的好处是你可以直接开始构建框架，你的团队可以随时在需要的时候做出新的定制选项相应的决定和变化。只需转到SuperLinter并将模板从TEMPLATES文件夹复制到本地存储库。
