title: Adapting the git-flow model for pre-production environments
body: <p>I am thinking of extending the git-flow model for my current workplace, due to a particular scenario. But my scenario is so common that I'm surprised no-one's done this before with the git-flow model, and this makes me think I've missed an obvious problem. My question is: Is my proposed extension flawed?</p>
  <p>The scenario: I have a number of development teams who develop from a common codebase, and we push out releases through several (permanent) environments: first to the systems integration environment (SIT), then to the UAT environment, then to pre-prod, and finally to production. This is strictly sequential, although any release candidate may fail in any environment, and so not make it any further. Thus each later environment is simply a slower-moving version of the previous environment.</p>
  <p>We are introducing git for source control, we need a workflow, and git-flow looks like a good start.</p>
  <p>We asked ourselves how to capture (i.e. how to know) what's in each environment at any time. The git-flow model seems to have essentially two core states: <code>main</code> and <code>develop</code>. They have an &quot;infinite lifespan&quot;. Other branches are just <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">&quot;supporting branches&quot;</a> with a &quot;limited life time&quot;. They exist only to allow development and to go from development to production (via a temporary release state). The git-flow model is based around going from development to release.</p>
  <p>However, this doesn't map logically onto our scenario, with its multi-stage release sequence. I'm fine with the <code>develop</code> branch, of course. And the <code>main</code> branch clearly does map to our production environment. The <a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow noreferrer">original git-flow description</a> says this about <code>main</code>:</p>
  <blockquote>
  <p>Therefore, each time when changes are merged back into main, this is a new
  production release <em>by definition</em>. We tend to be very strict at this, so that
  theoretically, we could use a Git hook script to automatically build and roll-out
  our software to our production servers everytime there was a commit on main.</p>
  </blockquote>
  <p>Since <code>main</code> is a continuous record of production, it seems consistent that we should <em>extend the git-flow model</em> to have corresponding branches for SIT, UAT, and pre-prod. After all, they are permanent environments, with strict release procedures. They just change a bit quicker than production.</p>
  <p>These additional, permanent, branches sit between <code>develop</code> and <code>main</code>, just as their corresponding environments do.</p>
  <p>This now means it's easy to track releases to each environment, and the state of each environment. And merges for each are easier, too: the SIT branch requires a merge from <code>develop</code>, the UAT branch requires a merge from the SIT branch, the pre-prod branch requires a merge from the UAT branch, and finally the <code>main</code> branch (for production) requires a merge from the pre-prod branch. Each later branch is simply a slower-moving version of the previous branch.</p>
  <p>Have I missed something?</p>