1 分•作者: habosa•7 个月前
嗨，HN，
我参与过的每个团队都曾拼凑过某种 GitHub 分支保护和自定义脚本的组合，以确保 PR 遵守组织策略和最佳实践。
例如：
- 当 {X} 文件被更改时，需要团队 {Y} 的审查
- 当添加新的数据库迁移时，确保通过一组特殊的测试
- 当 PR 非常大时，需要多个审批
- 为包含重大更改的 PR 添加特殊标签
- 允许紧急情况/热修复打破常规，绕过以上所有限制
大多数团队倾向于从在 GitHub Actions 中运行的小脚本开始，以执行所有这些策略，但它往往会失控并变得难以维护。本应受到审查的 PR 却被忽略，而本应允许通过的 PR 却被不必要地阻止。
这就是我创建 GitGuard 的原因（<a href="https://gitguard.dev/" rel="nofollow">https://gitguard.dev/</a>）
GitGuard 允许您使用自定义 DSL 编写和维护这些策略，它非常简单，看起来就像伪代码。这些策略会在每个 PR 上几乎瞬间被检查（无需等待 GitHub Actions 运行器），并且结果以通俗易懂的语言报告。
目前，策略可以对 PR 元数据进行简单的断言并采取一些有状态的操作（添加标签、请求审查），但我很乐意从 HN 听到更多关于 GitGuard 如何变得更有用的信息。