治理
规则，真的有人遵守。
一份规则目录，处处适用。
分支策略、代码审查、编码规范、决策记录、规格驱动开发：每一项都是同一目录中的一条规则，可通用，也可按条件适用。规则及其背后的文件会被带进每个受治理的代码仓库；哪个代码仓库偏离了规则，就会收到一个经过审查、把它拉回来的变更。
- 同一个规则目录，通用或按条件适用
- 以经过审查的变更进入每个代码仓库
- 偏离会以变更的形式回到该代码仓库
分支保护。说好话也没用。
代理向您指定的集成分支提交 pull request，支持 GitHub、GitLab、Bitbucket 和 Azure DevOps。机器上的守卫会拒绝任何推送到该分支或 main 的操作，分支前缀把机群圈在范围内，关闭推送开关则会彻底移除推送地址。
- 集成分支、分支前缀和推送开关，按项目设置
- 推送时即被拒绝，就在机器本身
- 关卡命令和常驻指令，按项目设置
每条规则、每个代码仓库，一张表格。
每条规则对照每个代码仓库，尽在一张表格：最新、落后、偏离、受阻、已退出。强制规则未通过即为缺陷，代理会提交修复它的变更；建议规则则会报告。随时可以重新扫描全部代码仓库。
- 强制与建议两档
- 未通过的项，自动提交修复
- 随时重新扫描
三道审查，不走过场。
独立审查者阅读变更和规格：一次代码审查、一次安全审查，以及一次对照验收项的检查。阻塞问题在发布前修复；涉及身份验证、凭据、数据库迁移或个人数据的变更，要等一个人来把关。
- 代码审查、安全审查、验证——各自独立一轮
- 阻塞问题发布前修复
- 安全敏感的变更等人工把关
受治理的代码仓库里有什么
同一小套文件，进驻每个代码仓库。
每个受治理的代码仓库都带着同一小组文件，代理在哪里都能在同一位置找到规则。
- 根目录的中枢文件：硬性规则，外加通往其他一切的索引
- 构成规则的各项策略——分支策略、代码审查、编码规范、决策记录
- 代理运行的检查脚本，以及在每次 commit 和推送前运行它的钩子
- 代理根据当前技术栈加载的技能