GitHubのプルリクエストモデルは、承認後の実装に使用できますか？

「four-eyes原則の可能な実装（または例）は何ですか？」に対する受け入れられた回答は、GitHubのプルリクエストモデルが可能な実装であることを示唆しています。

そして、「緊急修正の四目原理を実装する方法」に対する私自身の回答は、承認後の概念を説明しています。

私の質問：GitHubのプルリクエストモデルは、承認後の実装にも使用できますか？もしそうなら：どのように？そうでない場合、Git（GitHub？）で他に使用できるものはありますか？

はい、そう思います。私が同様のものを実装する方法に基礎を置く必要があることを説明するために、できるだけ明確にするためにモデルを簡略化しました。

仮定

ここでは、選択したCI / CDツールとしてJenkins、TeamCityなどが使用されていることを前提としています。さらに、GitHubが使用されており、明確に定義され、適切に制御された分岐構造があります。

構成

この例では、GitHubは次のように構成されています。

• ブラックの「マスター」ブランチは、プルリクエストを使用してのみマージできます。直接コミットは許可されません。
• Blue 'Development'ブランチは、直接コミットまたはマージを受け入れることができます。実際には、このブランチには追加の制限がある場合があります。
• Red 'Hotfix'ブランチは、直接コミットおよびマージを受け入れることができます。
• 必須ステータスチェックは、ブランチがビルドに失敗したときにプルリクエストがマージされるのを防ぐために、厳密モードで有効になっています。
• 修正プログラムのブランチが先マスターのであれば、要求を引くにマスターのいずれかで、ブロックされますステータスAPIまたはGitHubのエンタープライズの事前受信フック。

CI / CDツールは次のように構成されています。

• 開発ブランチからのビルドは、本番環境にデプロイできません。
• マスターからのビルドは、すべての環境にデプロイできます。
• Hotfixからのビルドは、すべての環境に展開できます。
• Hotfixからの展開では、一部の非開発機能（たとえば、変更/リリースチーム）に通知し、承認後の実行を依頼します。

ノート

マスターは現在の運用状態を表すため、保護されています。これを実際に行うには、マスターブランチへのマージが成功した場合にのみ、デプロイメントが行われる別の「リリース」ブランチがある場合があります。

キーポイント

Blue Developmentブランチは基本的に無料です。Hotfixは無料で提供されますが、どのような展開でも、承認後の作業を行い、変更をマスターにマージする開発以外の機能に通知することにより、一種のBreak Glassをトリガーします。

HotfixがMasterよりも先にある間は、Master stopにマージすることが不可欠です。

1. マスターがホットフィックスを上書きしないように配置すると、回帰が発生する可能性があります。
2. HotfixブランチにあるHotfixがマージされずに弱体化するのを防ぎます。

一部の組織では、Hotfixが承認後に保留されている間、中央のGitHubリポジトリへのすべてのプッシュを防止するのに役立つ場合があります。