title: Workflow that enforces code review and keeps the integration branch pristine (git, Stash, TeamCity)
body: <p>I'm trying to design a new workflow that follows these principles:</p>
  
  <ul>
  <li>Only commits that have passed automatic verification (CI) should be merged into the mainline (specifically the merged state should pass CI to keep the integration branch as pristine as possible)</li>
  <li>Only commits that have passed human code review should be merged into the mainline</li>
  <li>Only commits that have passed automatic verification should be reviewed by another human (if it doesn't even build and pass tests, don't waste someone else's time on it)</li>
  <li>Feature branches should be covered by CI (independently, not merged into the integration branch - this is helpful for devs during development) </li>
  </ul>
  
  <p>We are using git, Stash and TeamCity. This is what I have come up with, but none of them are perfect. I'm looking for tweaks to my suggestions, or new ideas.</p>
  
  <p>WORKFLOW 1</p>
  
  <ul>
  <li>Developer develops on feature/VHPC-1 (feature branches are covered by normal CI in TeamCity)</li>
  <li>When the feature is done, the developer creates a pull request: feature/VHPC-1 --> mainline</li>
  <li><p>When the pull request is approved by another developer, it is automatically merged into the mainline by Stash (mainline is covered by normal CI in TeamCity)</p></li>
  <li><p>Problem: Stash will not perform the merge if there are merge conflicts, but the merged state is not tested at all until after the merge to mainline. We don't know if the mainline will break until it does.</p></li>
  </ul>
  
  <p>WORKFLOW 2</p>
  
  <ul>
  <li>Developer develops on feature/VHPC-1 (feature branches are covered by normal CI in TeamCity)</li>
  <li>The developer pushes from feature/VHPC-1 to feature/VHPC-1/review (where we rebase the integration branch and then do CI (testing the merged state))</li>
  <li>When the feature is done, the developer creates a pull request: feature/VHPC-1/review --> mainline</li>
  <li><p>When the pull request is approved by another developer, it is automatically merged into the mainline by Stash (mainline is covered by normal CI in TeamCity)</p></li>
  <li><p>Problem: The time (20 min - 1 day?) between the merged state is tested and the integration happens allows changes in the integration branch which could mean the merged state no longer works. Chance that integration branch breaks.</p></li>
  <li>Problem: Twice the number of branches means some extra complexity and work.</li>
  </ul>
  
  <p>WORKFLOW 3</p>
  
  <ul>
  <li>Developer develops on feature/VHPC-1 (feature branches are covered by normal CI in TeamCity)</li>
  <li>When the feature is done, the developer creates a pull request: feature/VHPC-1 --> feature/VHPC-1/review</li>
  <li><p>When another developer approves and merges the pull request, feature/VHPC-1/review will be automatically built and tested in the merged state, and automerged to mainline on success</p></li>
  <li><p>Problem: Twice the number of branches means some extra complexity and work.</p></li>
  <li>Problem: Commits must always be integrated into mainline, and only cherry-picked to release branches.</li>
  </ul>
  
  <p>WORKFLOW 4</p>
  
  <ul>
  <li>Developer develops on feature/VHPC-1 (feature branches are covered by
  normal CI in TeamCity) </li>
  <li>When the feature is done, the developer
  creates a pull request: feature/VHPC-1 --> mainline TeamCity
  automatically adds itself a reviewer, and tries to build and test the
  pull request - in the merged state (using Stash's undocumented
  refs/pull-requests/merge) </li>
  <li><p>If the automatic verification passes,
  TeamCity will approve the pull request. A human may then review,
  approve and merge it into the mainline. </p></li>
  <li><p>Problem: TeamCity monitors
  refs/pull-requests/merge which changes when the integration branch
  changes, meaning a build would be triggered on all open pull requests
  when the integration branch gets one new change.</p></li>
  </ul>