原文链接：
一个成熟团队的 GitHub 协作配置，可以按这条链路建设：
Issue / ADR / Ticket
-> short-lived branch
-> draft PR
-> CODEOWNERS routing
-> CI
-> security checks
-> required review
-> merge queue
-> protected main
-> tag / release
-> deploy
这套配置适合 GitHub Flow，也能承载 trunk-based 风格的团队协作。
目标：避免直接在主分支上开发。
建议：
目标：让懂对应代码的人参与 Review。
建议：
目标：把团队规则固化到平台。
建议：
mainBranch Protection 更适合单仓库、少量关键分支起步。Rulesets 更适合组织级、多仓库、规则叠加和审计可见性。
目标：把常见安全问题前移到 PR 和 push 阶段。
建议：
Dependabot 可以把依赖和 GitHub Actions 版本升级变成 PR，Code scanning 负责发现代码安全问题，Secret scanning 负责发现凭证泄露风险。这三类检查适合和 PR 流程绑定，不能只做事后扫描。
目标：合入前验证主分支组合结果。
建议：
merge_group 事件触发 CI目标：让上线版本可追踪、可解释、可回滚。
建议：
GitHub Flow 是 GitHub 平台上的轻量协作路径，核心是短分支、PR、Review、合入默认分支。
Trunk-Based Development 是更强的组织原则，强调围绕主干高频集成，分支生命周期极短，主干持续可发布。
当一个团队在 GitHub Flow 上加上：
它就已经很接近 trunk-based 的企业实现形态。
不要一次性把所有能力打开。
推荐顺序：
GitHub 更像统一开发平台，优势是 PR、Actions、安全扫描、Issue、Release、Rulesets 一体化。
Gerrit 更像评审中枢，优势是组级权限、label 投票、Submit 权限和更细的评审语义。
如果团队需要特别强的 Review 权限模型，可以参考 Gerrit 代码评审治理参考。如果团队希望围绕 GitHub 生态建设统一协作平台，则优先用 GitHub 原生能力组合。
如果团队有 release/*、hotfix/* 或生产 tag，也要设计规则。
CI 越慢，开发者越倾向绕过规则。
扫描只是发现问题，还需要 owner、处理时限和升级路径。
使用 GitHub Actions 时，关键 workflow 要响应 merge_group：
on:
pull_request:
merge_group:
GitHub 工程治理不要写成工具清单。
更适合写成从变更提出到发布完成的协作链路，让读者知道每个工具解决哪个风险点。