title: Git Flow: Implications of merging to release branch instead of develop (aka easiest way to correct merge issues)
body: <p>We have recently started using Git Flow branching strategy and somehow I was put in charge of being a &quot;release manager&quot;.  I know Git Flow says feature branches should be merged into the <code>develop</code> branch but I'm wondering the implications of instead creating the <code>release/x.x.x</code> branch much earlier and merging features there and then testing from the release branch (and eventually merging to develop/master).  The reason would be we have some junior developers and if things go sideways it's easier to just delete the <code>release/x.x.x</code> branch and recreate / re-merge the feature branches.  If the developers continue to branch off <code>develop</code> the only downside I can think of is their code won't be aware of current developed/finished feature branches so merges to release may end up with more conflicts.  Am I overcomplicating this?</p>
  <p>If I am can you point out some resources on how to deal with issues with merged code.  Are my only two choices essentially: 1) Potentially screw the timeline / hold the release and put the original developer on fixing the code issue and 2) resetting to a known good branch, force pushing, and make everyone sync up and remerge known good changes?</p>