在设置新的存储库时，为不同类型的代码选择合适的对应 linter 可能是既费时又乏味的工作。可供选择的工具和配置如此之多，我们通常需要不止一个 linter 才能涵盖所有用到的语言。

　　GitHub Super Linter 是由 GitHub Services DevOps 工程团队根据需要构建的，目的是保持我们文档和代码的一致性，同时提升整个公司之间的交流和协作的效率。现在我们正式将其开源，这样所有人都可以使用和改进它了！

　　Super Linter 通过自动化解决了许多需求。其特性包括：

• 防止将损坏的代码上传到主分支；
• 帮助建立多种语言的编码最佳实践；
• 制订代码布局和格式的指南；
• 自动化流程以帮助简化代码审查；
• 有了这些基础标准后，我们就能在内部 / 向客户和合作伙伴交付更好、更整洁、更稳定的代码。

　　它是什么？

　　Super Linter 是一个源代码存储库，它打包到一个 Docker 容器中，并由 GitHub Actions 调用。这样 GitHub.com 上的任何存储库都可以调用 Super Linter 并从中获益。

　　目前 Super Linter 支持多种语言，将来还会提供更多语言支持。有关支持语言的详细信息，请查看 README.md 。

　　工作机制

　　将存储库设置为开始运行这个动作（Action）后，只要你打开一个拉取请求，存储库就会开始 linting 代码并通过 Status API 返回。它会通知你所有代码更改是否成功通过，或者是否检测到任何错误，错误在哪里以及它们的具体信息。然后，开发人员可以返回其分支，解决所有问题，并为这个开放的 PR 创建一个新的 push。届时，Super Linter 将再次运行和验证更新代码，并重复该过程。你可以配置分支保护规则，加入 ” 所有代码在合并前必须通过 ” 的额外规定。

　　Super Linter 拥有大量带有标志和模板的自定义选项，你可以针对自己的存储库调整它们。只需按照 Super Linter 存储库和 Super Linter Wiki 上的详细说明操作即可。

　　这款工具对于将多种类型的代码和 / 或文档放在一起的存储库（单体存储库）来说也很有用。

　　默认规则

　　在 Super Linter 中标准化一个规则集是一项有趣的挑战，因为每位开发人员的编码方式都是独一无二的。所以我们允许用户根据他们自己的存储库情况对 Linter 使用任何规则。但如果用户未定义规则集，则我们必须有一个默认标准。

　　Ruby 和 Rails 的规则集来自 Ruby gem： rubocop-github ，并遵循我们在 GitHub.com 上使用的同一套规则和版本控制策略。

　　对于其他语言，我们指定了安装 linter 时的默认项，例如： coffeelint 或 yamllint 。至于剩下的那些，我们尝试找到一个合适的平衡点——基础简单且能帮助建立一些最佳实践，例如： Markdownlint 或 pylint 。

　　这样做的好处是，你可以直接开始建立框架，并且当需要新的自定义选项时你的团队可以随时做出相应的决策与改动。

　　只需转到 Super Linter，然后将模板从 TEMPLATES 文件夹复制到本地存储库即可。

　　英文原文：Introducing GitHub Super Linter: one linter to rule them all