我自己的回答是：“如何实现紧急修复的四眼原则？”解释了批准后的概念。
我的问题：GitHub的Pull Request模型也可以用于实施批准后吗？如果是这样：如何？如果没有，我可以在Git（GitHub）中使用其他功能吗？
#1 楼
是的，我确实相信。为了说明我需要为实现类似方法打下基础，我简化了该模型，以使其尽可能清晰。假设
我在这里假设Jenkins，TeamCity或类似产品被用作选择的CI / CD工具。另外，还使用了GitHub，并且有一个定义明确且受到适当控制的分支结构：的配置如下：
黑色的“ Master”分支只能使用“拉取请求”合并，不允许直接提交。
蓝色的“ Development”分支可以接受直接提交或合并；实际上，此分支上可能会有其他限制。
红色的“ Hotfix”分支可以接受直接提交和合并。
在严格模式下启用了必需的状态检查，以防止在分支处于合并状态时合并请求构建失败。
如果Hotfix分支在Master之前，则使用Status API或GitHub Enterprise上的Pre-Receive Hooks阻止向Master的拉取请求。
CI / CD工具的配置如下：
不能将Development分支的构建部署到生产环境。
Master的构建可以部署到所有环境。
构建Hotfix的部署可以部署到所有环境。
Hotfix的部署将通知一些非开发功能，例如，变更/发布团队，并要求他们执行批准后的操作。
注意
主设备受到保护，因为它代表了当前的生产状态，实际上，您可能会拥有另一个“发行”分支仅在成功合并到Master分支后才进行帽子部署。
关键点
Blue Development分支基本上是免费的。修补程序是一种免费的工具，但是任何部署都会通过通知将要进行批准的非开发部门来触发碎玻璃，该过程将更改合并到Master中。
在Hotfix领先于Master之前，它必不可少地合并到Master停止中：
防止Master覆盖Hotfix进行部署，这可能导致回归。
防止a坐在Hotfix分支中的Hotfix在没有合并的情况下就失效了。
在某些组织中，当Hotfix待批准后待批准时，这可能有助于防止所有推送到中央GitHub存储库。
评论
好的理查德，怜悯！我将消化您在anwer中编写的一些内容，并可能在以后添加一些额外的注释，以澄清/完成您编写的一些内容。在适当的地方，我可能还会添加后续问题。熟悉诸如“问题的答案会触发10个新问题……”之类的东西吗？
–Pierre.Vriens♦
17 Mar 26 '17 at 18:05
@ Pierre.Vriens请问很多问题，我已经有效地从内存的客户端企业GitHub Enterprise和Jenkins的实现中提取了上述内容-可能我错过了一些东西，花了我4个小时来编写它因为我非常仔细地检查。至于“问题的答案会引发10个新问题”，这在咨询中非常普遍。
–Richard Slater
17 Mar 26 '17 at 18:40
您是否有机会将问题写在“纸上”？如果愿意，很高兴在聊天中谈论它。
–Richard Slater
17年4月3日在15:36
评论
厨师贡献过程的描述是否有意义？用链接引用它会是窃，而且我认为我不会在提示之上添加任何内容。Bonjoiur @Tensibai ...我不知道该流程如何用于/考虑进行此类后期审批（必须是我不了解该流程）。因此，也许您应该添加一个答案（参考该链接），并添加一个解释，为什么您认为这样的过程确实回答了我的问题？
我想我会重复理查德已经说过的一堆话。要点是维护者有权合并到主服务器中，因此他们可以遵循相同的方案，批准自己的工作，并且以后仍然可以进行审查。
总而言之，这是Github设置问题答案的方法：)