Git Flow: Implications of merging to release branch instead of develop (aka easiest way to correct merge issues)

My suggestion is to stick with what’s recommended in GitFlow so that it will not cause any future confusion. I also would suggest to ask the developer who is in charge of the feature branch to fix the issue in the feature branch before creating a pull request to merge it to the develop branch. A release should always initiate from develop branch and the release branch should be merged in to the master. You can have hook or setup permission for how it needs to be code reviewed before it’s been merged in the future.

I agree with you that it's pretty easy to throw away release branches gone sideways, and the reason it's easy to do it is because most work isn't branching off of release and wouldn't be impacted by the branch going away. Your suggestion of having developers continue to branch off of develop, but merge into release, keeps the idea alive, but as you point out:

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.

That is a big downside, and likely enough to make it insurmountable. It also means you can't use a rebase workflow, which is personally my favorite way to keep feature branches up to date with the target branch. (Note even while rebasing we still force a merge commit, ideally making a short bubble in the graph for every feature branch merge. This is sometimes called a "Semi-Linear" merge strategy.)

Both of your proposed ideas would work, but fortunately I think there's a better option.

My company had nearly the identical problem a few years ago, though in our case it wasn't just Junior devs that had the problem; we also had certain applications that were difficult to fully test before code was merged into develop and deployed to one of our shared testing environments. We solved this problem by adding another branch called pre-develop which was a throwaway branch that was reset to the latest develop every day. The pre-develop branch was built and deployed to a Dev environment for testing outside of a developer's laptop. Once they are happy with the results, they PR it into develop. After a while of doing this, we realized that the maintainers of Git do something very similar, which is called gitworkflows. (Sometimes it's also called gitworkflow; singular without the 's'.) Additional reading here. Since gitworkflows calls the throwaway branch next, we renamed pre-develop to next which in our case represents the "next changes to go into develop". We also changed our reset frequency to be once per week instead of daily, since developers wanted more time to finish their testing and to get their Product Owners to sign off on it. Now we consider our Git Branching Strategy to be a hybrid of gitworkflows and Git Flow.