title: Git branch strategy with multiple parallel feature release into the same application
body: <p>We are developing modules for a web app that are released in parallel. We are trying to figure out a good branching strategy to keep an overview of the released modules. This is our current system:</p>
  
  <ul>
  <li>Master: contains all released modules / code (matches production)</li>
  <li>env/test: Branch that is deployed to the testing environment</li>
  <li>env/acceptance: Branch that is deployed to the acceptance environment</li>
  <li>env/production: Branch that is deployed to the production environment</li>
  </ul>
  
  <p>Since modules are being developed and released in parallel one module could be started after another and be released earlier. To make this work a new module starts with a feature branch from master. This feature branch is squashed merged into env/test to create a single commit for the new module. Now the difficult part starts. To prevent merges into the env/* branches we have added a policy to force squash merges. For test this is working correctly since it is the first place a new module / feature is merged to. When we squash merge into acceptance / production and master we loose a reference between master and the env/* branches. We would like to maintain a reference so we can check how much acceptance is ahead of master (unreleased modules in acceptance stage). </p>
  
  <p>We know this is not the best solution but are struggling to figure out a better strategy. The clients really want to maintain the parallel development since some modules can take months in the acceptance stage (many stakeholders ect) and some can be released in a week. Using a fixed numbered release system would delay some modules and would introduce other issues when a module is cancelled during acceptance.</p>