<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>

CC BY-SA 3.0
2017-03-26T18:05:27.737Z
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 ..."?
Pierre.Vriens
CC BY-SA 3.0
2017-03-26T18:40:11.220Z
@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.
Richard Slater
CC BY-SA 3.0
2017-04-03T15:36:35.100Z
Did you ever get a chance to get the questions down on "paper"?  Happy to talk over it in chat if you prefer.
Richard Slater
CC BY-SA 3.0
2017-03-26T17:19:01.543Z
2017-03-26T17:19:01.543Z
Richard Slater
<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>

CC BY-SA 3.0
2017-03-27T07:57:27.563Z
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.
Tensibai
CC BY-SA 3.0
2017-03-27T08:17:23.430Z
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?
Pierre.Vriens
CC BY-SA 3.0
2017-03-27T08:46:02.503Z
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.
Tensibai
CC BY-SA 3.0
2017-03-27T12:08:20.407Z
All in all, this is the Github way to set in place your answer linked in your question :)
Tensibai
<git><configuration><four-eyes>
Can GitHub's Pull Request model be used for implementing post approvals?
Pierre.Vriens
# 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 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.  
> **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 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 ..."?  
> **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.  

---

