Answers: <p>Yes, I do believe so.  To explain that I need to lay some groundwork on how I have implemented something similar, I have simplified the model in an attempt to make it as clear as possible.</p>
  
  <h2>Assumptions</h2>
  
  <p>I am making the assumption here that Jenkins, TeamCity or similar is being used as the CI/CD tool of choice. Additionally GitHub is being used and that there is a well-defined and <a href="https://help.github.com/articles/about-branch-restrictions/" rel="nofollow noreferrer">appropriately controlled</a> branching structure:</p>
  
  <p><a href="https://i.sstatic.net/uA5zC.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/uA5zC.png" alt="Branching Diagram"></a></p>
  
  <h2>Configuration</h2>
  
  <p>In this example, GitHub is configured as follows:</p>
  
  <ul>
  <li>The Black 'Master' branch can only be merged into using <a href="https://help.github.com/articles/enabling-required-reviews-for-pull-requests/" rel="nofollow noreferrer">Pull Requests</a>, direct commits are disallowed.</li>
  <li>The Blue 'Development' branch can accept direct commits or merges; in practice, there may be additional restrictions on this branch.</li>
  <li>The Red 'Hotfix' branch can accept direct commits and merges.</li>
  <li>Required Status Checks <a href="https://help.github.com/articles/about-required-status-checks/" rel="nofollow noreferrer">are enabled</a> in strict mode to prevent pull requests merging when the branch is failing the build.</li>
  <li>If the Hotfix branch is ahead of Master then pull requests <em>into</em> Master will be blocked, either with the <a href="https://developer.github.com/v3/repos/statuses/" rel="nofollow noreferrer">Status API</a> or the <a href="https://help.github.com/enterprise/2.9/user/articles/working-with-pre-receive-hooks/" rel="nofollow noreferrer">Pre-Receive Hooks on GitHub Enterprise</a>.</li>
  </ul>
  
  <p>The CI/CD tools are configured as follows:</p>
  
  <ul>
  <li>Builds from the Development branch cannot be deployed to production.</li>
  <li>Builds from Master can be deployed to all environments.</li>
  <li>Builds from Hotfix can be deployed to all environments.</li>
  <li>Deployments from Hotfix will notify some non-development function, for example, the Change/Release team and ask them to perform the <em>post-approval</em>.</li>
  </ul>
  
  <p><strong>Notes</strong></p>
  
  <p>Master is protected as it represents the current state of production, to do this practically you may have another "Release" branch that deployments are made from and only when successful merge into the Master branch.</p>
  
  <h2>Key Points</h2>
  
  <p>The Blue Development branch is basically a free-for-all.  Hotfix is kind of a free-for-all but any deployments trigger a type of <a href="https://security.stackexchange.com/questions/14430/in-healthcare-it-is-a-break-glass-mode-to-bypass-access-controls-commonly-req">Break Glass</a> by notifying a non-development function who will perform the <em>post-approval</em> and in the process will merge the change into Master.</p>
  
  <p>It's essential merges into Master stop while Hotfix is ahead of Master to:</p>
  
  <ol>
  <li>Prevent a deployment from Master overwriting the Hotfix, which could result in an regression.</li>
  <li>Prevent a Hotfix sitting in the Hotfix branch languishing without being merged in.</li>
  </ol>
  
  <p>In some organisations it may help to prevent all pushes to the central GitHub repository while a Hotfix is pending post-approval.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-26T18:05:27.737Z
Answers: Nice Richard, merci! I'm going to digest a few of the things you wrote in your anwer, and possibly add some extra comments later on to clarify/complete a few things you wrote about. Where appropriate I might add followup-question(s) also. Are familiar with somthing like "the answer to a question triggers 10 new questions ..."?
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-26T18:40:11.220Z
Answers: @Pierre.Vriens please do ask plenty of questions, I've effectively extracted the above out of a client's implementation of [GitHub Enterprise](https://enterprise.github.com/home) and [Jenkins](https://jenkins.io/) and entirely from memory - it is possible I have missed something, it did take me 4 hours to write it as I was checking very carefully.  As to "the answer to a question triggers 10 new questions" it's very common in consulting.
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2017-04-03T15:36:35.100Z
Answers: Did you ever get a chance to get the questions down on "paper"?  Happy to talk over it in chat if you prefer.
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2017-03-26T17:19:01.543Z
Answers: 2017-03-26T17:19:01.543Z
Answers: Richard Slater
Body: <p>The accepted answer to "<a href="https://devops.stackexchange.com/q/337/40">What are possible implementations (or examples) of the four-eyes principle?</a>" suggests that GitHub's <a href="https://help.github.com/articles/about-pull-requests/" rel="nofollow noreferrer">Pull Request model</a> is a possible implementation.</p>
  
  <p>And my own answer to "<a href="https://devops.stackexchange.com/q/437/40">How to implement the four-eyes principle for emergency fixes?</a>" explains the concept of <strong><em>post-approvals</em></strong>.</p>
  
  <p><strong>My question</strong>: Can GitHub's Pull Request model be used for implementing post approvals also? If so: how? If not, is there anything else in Git (GitHub?) that I could use for it?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-03-27T07:57:27.563Z
Comments: Does the description of Chef's [Contribution Process](https://github.com/chef/chef/blob/master/CONTRIBUTING.md#contribution-process) makes sense ? quoting it with a link would be plagiarism, and I don't think I will add anything on top of tip.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-27T08:17:23.430Z
Comments: Bonjoiur @Tensibai ... I don't understand how that process could be used/considered for such post approvals (must be me who doesn't get it). So maybe you should add an answer   (with reference to that link), and add   an explanation why you think such process does answer my question?
Comments: Pierre.Vriens
Comments: CC BY-SA 3.0
Comments: 2017-03-27T08:46:02.503Z
Comments: I assume I'll be repeating a bunch of what Richard's already said. The main point is the maintainers have a right to merge in master, so they can follow the same scheme, approving their own work and still being able to review it later.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-03-27T12:08:20.407Z
Comments: All in all, this is the Github way to set in place your answer linked in your question :)
Comments: Tensibai
Tags: <git><configuration><four-eyes>
Title: Can GitHub's Pull Request model be used for implementing post approvals?
UserDisplayName: Pierre.Vriens
ThreadText: # Can GitHub's Pull Request model be used for implementing post approvals?
  
  (Asked by: username_0 on 2017-03-26)
  
  The accepted answer to "[What are possible implementations (or examples) of the four-eyes principle?](https://devops.stackexchange.com/q/337/40)" suggests that GitHub's [Pull Request model](https://help.github.com/articles/about-pull-requests/) is a possible implementation.
  
  And my own answer to "[How to implement the four-eyes principle for emergency fixes?](https://devops.stackexchange.com/q/437/40)" explains the concept of ***post-approvals***.
  
  **My question**: Can GitHub's Pull Request model be used for implementing post approvals also? If so: how? If not, is there anything else in Git (GitHub?) that I could use for it?
  
  **Tags:** git, configuration, four-eyes
  
  > **Comments:**
  > **username_1**: Does the description of Chef's [Contribution Process](https://github.com/chef/chef/blob/master/CONTRIBUTING.md#contribution-process) makes sense ? quoting it with a link would be plagiarism, and I don't think I will add anything on top of tip.  
  > **username_0**: Bonjoiur @username_1 ... I don't understand how that process could be used/considered for such post approvals (must be me who doesn't get it). So maybe you should add an answer   (with reference to that link), and add   an explanation why you think such process does answer my question?  
  > **username_1**: I assume I'll be repeating a bunch of what username_2's already said. The main point is the maintainers have a right to merge in master, so they can follow the same scheme, approving their own work and still being able to review it later.  
  > **username_1**: All in all, this is the Github way to set in place your answer linked in your question :)  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-03-26. Score: 4
  
  Yes, I do believe so. To explain that I need to lay some groundwork on how I have implemented something similar, I have simplified the model in an attempt to make it as clear as possible.
  
  ## Assumptions
  
  I am making the assumption here that Jenkins, TeamCity or similar is being used as the CI/CD tool of choice. Additionally GitHub is being used and that there is a well-defined and [appropriately controlled](https://help.github.com/articles/about-branch-restrictions/) branching structure:
  
  [![Branching Diagram](https://i.sstatic.net/uA5zC.png)](https://i.sstatic.net/uA5zC.png)
  
  ## Configuration
  
  In this example, GitHub is configured as follows:
  
  * The Black 'Master' branch can only be merged into using [Pull Requests](https://help.github.com/articles/enabling-required-reviews-for-pull-requests/), direct commits are disallowed.
  * The Blue 'Development' branch can accept direct commits or merges; in practice, there may be additional restrictions on this branch.
  * The Red 'Hotfix' branch can accept direct commits and merges.
  * Required Status Checks [are enabled](https://help.github.com/articles/about-required-status-checks/) in strict mode to prevent pull requests merging when the branch is failing the build.
  * If the Hotfix branch is ahead of Master then pull requests *into* Master will be blocked, either with the [Status API](https://developer.github.com/v3/repos/statuses/) or the [Pre-Receive Hooks on GitHub Enterprise](https://help.github.com/enterprise/2.9/user/articles/working-with-pre-receive-hooks/).
  
  The CI/CD tools are configured as follows:
  
  * Builds from the Development branch cannot be deployed to production.
  * Builds from Master can be deployed to all environments.
  * Builds from Hotfix can be deployed to all environments.
  * Deployments from Hotfix will notify some non-development function, for example, the Change/Release team and ask them to perform the *post-approval*.
  
  **Notes**
  
  Master is protected as it represents the current state of production, to do this practically you may have another "Release" branch that deployments are made from and only when successful merge into the Master branch.
  
  ## Key Points
  
  The Blue Development branch is basically a free-for-all. Hotfix is kind of a free-for-all but any deployments trigger a type of [Break Glass](https://security.stackexchange.com/questions/14430/in-healthcare-it-is-a-break-glass-mode-to-bypass-access-controls-commonly-req) by notifying a non-development function who will perform the *post-approval* and in the process will merge the change into Master.
  
  It's essential merges into Master stop while Hotfix is ahead of Master to:
  
  1. Prevent a deployment from Master overwriting the Hotfix, which could result in an regression.
  2. Prevent a Hotfix sitting in the Hotfix branch languishing without being merged in.
  
  In some organisations it may help to prevent all pushes to the central GitHub repository while a Hotfix is pending post-approval.
  
  > **Comments:**
  > **username_0**: Nice username_2, merci! I'm going to digest a few of the things you wrote in your anwer, and possibly add some extra comments later on to clarify/complete a few things you wrote about. Where appropriate I might add followup-question(s) also. Are familiar with somthing like "the answer to a question triggers 10 new questions ..."?  
  > **username_2**: @username_0 please do ask plenty of questions, I've effectively extracted the above out of a client's implementation of [GitHub Enterprise](https://enterprise.github.com/home) and [Jenkins](https://jenkins.io/) and entirely from memory - it is possible I have missed something, it did take me 4 hours to write it as I was checking very carefully.  As to "the answer to a question triggers 10 new questions" it's very common in consulting.  
  > **username_2**: Did you ever get a chance to get the questions down on "paper"?  Happy to talk over it in chat if you prefer.  
  
  ---
  
  