Change merging of release branch step

[brianamarie]

Currently, users are approving a pull request that merges the release branch into master. After chatting with @hectorsector, this doesn't really mimc a realistic flow. Realistically, there are many smaller pull requests merged into the release branch.

I propose that we:

• Open the pull request at the same time
• Open an additional pull request from some branch into v1.0 or whatever the release branch is named
• Instruct users to approve the additional PR

After they do that, we'll merge the additional PR and point them back to the release PR, showing them that it has changes from multiple smaller PRs. At that point, we could:

• create a release from the branch, then merge (or not merge?) (not sure why we'd do this)
• remove the protected branch status and have the user merge, then continue as normal

[hectorsector]

https://github.com/githubtraining/release-workflow/blob/4a7d9df51e15bd855133e61d3588c3fbd913b3d6/config.yml#L82-L91

Editing the base of the PR feels odd and not realistic. I think this is aligned to what you were suggesting above, so how about this flow, @brianamarie?

• User opens a pull request against master for the purposes of project management
• After creating the release branch, user opens a new pull request against the release branch

[brianamarie]

• User opens a pull request against master for the purposes of project management
• After creating the release branch, user opens a new pull request against the release branch

I think I'm following but I'm not certain. What would the pull request against master be from? Would the user create the release branch first, then create their tracking PR, and then make the fix PR? If so I'm on board but if not I think I still don't understand. 😊

[hectorsector]

@brianamarie I think we ironed this out in #16. Please feel free to reopen if I'm wrong.