title: Is this a good or acceptable branching strategy for continuous delivery with azure git devop?
body: <p>We are using azure pipeline with git repo. At the moment, we have a master branch, a sprint branch, and feature branches. For production deployment, we deploy sprint branch and then merge it back to master. </p>
  
  <p>The sprint branch will be deployed to dev, QA, UAT and Prod.
  However,  there are some practical issues after some months working:</p>
  
  <ol>
  <li>After each sprint, we have to remember merging back to master branch.</li>
  <li>To do hotfix, we need to create a branch from master, as normally we deploy from sprint branch, we have to spin off a new deployment pipeline and release pipeline for hotfix.</li>
  <li>If we want to deploy a couple of features only, it is not easy (as the sprint branch may contain features we do not want to deploy out, so have to revert.</li>
  </ol>
  
  <p>What we are thinking is doing this now:</p>
  
  <ol>
  <li>We still have Master, Sprint and feature branches. But now we only deploy to production from Master branch now.</li>
  <li>For sprint branch, we only deploy to Dev and QA environment. When sprint finish, we need to merge back to Master first and then deploy to UAT and then production.</li>
  <li>For hotfix, we create hotfix branch base on Master, and deploy to UAT and then production.</li>
  <li>To deploy a couple of features only, we could merge the needed features to Master branch and then deploy. However, this requires that we keep these feature branches after PR (as otherwise it will be difficult to find the feature branch).</li>
  <li>After each sprint, we run some job to automatically delete the feature branches.</li>
  </ol>
  
  <p>Seems this way everything is bit smoother. Is there any issue with my idea or some better way to do this?</p>