“能力”；“打碎玻璃”；和绕过Github分支保护以进行紧急修复？

对于我们的项目，我们使用Github对所有更改强制至少1名审阅者，管理员不例外

然而，总有一天我们需要紧急修复。这将需要加速合并一个分支机构，这只有在有其他人在场的情况下才能发生。但是如果周围没有人会发生什么呢

我们需要绕过代码审查要求

我们可以在合并时暂时禁用代码审查要求，但这是不可取的，因为无法了解何时完成了这项工作，而且这是一个仅适用于管理员的解决方案

我希望有一个可审计的方法来做这件事。一个常见的术语是“打破玻璃”，即打破玻璃并进行紧急合并和部署，因为这是一个紧急情况，没有人会查看您的代码

---

是否有人想出了一种在受Github保护的分支上实现这一点的方法？

在我工作的地方，我们使用一个名为的程序来管理分支保护，该程序基本上使用单个git存储库中的一个文件来管理存储库的设置。这允许在不授予管理员访问权限的情况下公开设置（并且organizer工具不允许用户执行公开或删除存储库之类的操作）。还有其他类似的工具

---

除此之外，或者简单地向用户提供对存储库的管理员访问权限，在Github中没有一种方法可以做到这一点。如果这是您真正担心的问题，那么使用Github API构建一个“打破应急玻璃”仪表板或slackbot并不太困难，它可以移除分支保护，甚至直接合并拉请求。

无论您是手动还是使用工具/API，我会小心临时修改分支保护规则，因为在该窗口期间很容易取消阻止所有打开的拉取请求（即，您有一个适用于大多数或所有PRs的主/主分支保护规则）。显然，这取决于你的情况，但我已经写过一些工具，当你考虑到人们可能会点击合并的事实时，它可能真的会引起一些头痛。p> 最好是在每个公关的基础上处理它。比如说，如果你设置了一个机器人来回复公关评论，并留下一个审批审查？这需要做一些工作，但您可能会使用GitHub操作（可以尝试）

有些人也使用它，这为代码审查规则提供了更大的灵活性。(). 在这种情况下看起来有点笨重，但您可以说，当PullApprove未启用时，它实际上应该具有通过状态：

#.pullapprove.yml
版本：3
Pullu条件：
-条件：“‘紧急’不在标签中”
未满足状态：成功
说明：“使用紧急标签检查禁用”
组：
...

标签更改直接显示在PR时间表中（包括更改者），因此审计跟踪将非常清晰：

---

不错，我想GHOM可以用来推动手动禁用分支保护的更改，然后允许合并，而且由于git的历史记录，这是可以审核的，如果这样做听起来很不错。谢谢合并机器人用户也是一个有趣的想法-你知道我们可以从哪些机器人开始使用正确的API调用等吗？事实上，是的，应用程序有。