title: Recommended git workflow that allows features to be deployed independently
body: <p>In our organization we're currently using the following flow.<a href="https://i.stack.imgur.com/3gBWK.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/3gBWK.png" alt="enter image description here"></a></p>
  
  <p>Feature branch is forked from the production branch. Feature is implemented in the feature branch on the developer machine. Then feature branch is merged into <code>develop</code> branch which is automatically deployed on staging server.</p>
  
  <p>The feature is tested by users on the staging server and if the business decides that it is good and that it is time to deploy it on live server, feature branch is merged second time, this time into the <code>production</code> branch which is deployed on the production server then.</p>
  
  <p>But some features are abandoned for various reasons. For example, business decides that it's not yet time to deploy the feature to the live server. Or maybe it's no longer required. Or maybe we'll return to it one year later. On my picture the <code>feature/1</code> is never merged into <code>production</code> branch but is merged into <code>develop</code> branch.</p>
  
  <p>This means that <code>develop</code> branch diverge more and more from the <code>production</code> branch. Note that <code>develop</code> is <strong>never</strong> merged to <code>production</code> (in the canonical git flow, <code>develop</code> is merged to <code>production</code> by using <code>release</code> branches).</p>
  
  <p>In my opinion this workflow requires a lot of manual labor. Because <code>production</code> and <code>develop</code> are different, manual merge is required when the feature branch is merged to <code>develop</code> for testing. This is also error-prone because we have old unused code from feature branches in <code>develop</code> that is never going away. Not only it makes merges complicated, but it also means that feature branch code may work differently in the <code>develop</code> and <code>production</code> branches because the old unmerged code can affect the feature code.</p>
  
  <p>Also, I have a feeling that with every new feature this will make the work more and more complicated because amount of differences between <code>develop</code> and <code>production</code> will inevitably grow. There's no point in flow where <code>develop</code> and <code>production</code> are reconciled, so I'm afraid that one year later and maybe 10,000+ commits later the merges will become simply too complex to handle. Even now we have merge bugs. Some are evident, some are subtle and very hard to find.</p>
  
  <p>I've raised the question several times to CTO that this flow is inherently inefficient and error-prone. But he insists that this flow is optimal because it allows business to choose when features are deployed to production. Also, he claims that he had used exactly the same flow at previous jobs in big companies.</p>
  
  <p>I also have a lot of experience but I never had seen such flow and I never read about such flow in a book or blog article.</p>
  
  <p>I have two questions:</p>
  
  <ol>
  <li>Is such flow (where <code>develop</code> and <code>production</code> are constantly diverging) indeed used in big teams?</li>
  <li>If I'm right that it is suboptimal at best, what is the best way to persuade the CTO to migrate to a better flow (for example, canonical git flow)?</li>
  </ol>