Should I replace my master branch with my release branch or merge my release branch into my master branch?
I'm currently attempting to move my team to this gitflow workflow and I am wondering if it's best to merge my release branch into my master branch once it's ready to go live or replace my master branch with my release candidate branch altogether.
We're doing all of our regression testing on the release candidate branch and are worried that my merging it into master it may affect it in some way making all of our regression testing ineffective.
Anyone ever had to deal with this before?
What you describe is a standard Git Flow, though the Atlassian documentation doesn't seem to clearly illustrate this part of the process. What you'll want to do is merge the release branch into your master branch, making sure to tag it:
You shouldn't 'replace' your master branch with the release branch. Your master branch is the 'core' of your project, and the master branch should be always be the 'last know good point', as you only ever push to master from either a release, or when there's a severe production bug and you're adding a hotfix.
In theory you should also be merging your release branch back to develop (as well as master) after a release, though if there are no hotfixes, the code will be identical and this won't be necessary.
There's no need to worry about somehow making regression testing ineffective -- regression testing should be done on the release branch, and you should be testing the changes each time a cut is made to the release branch. If this is your first release, there can't be any regressions, and there's nothing to regression test against.
You will, however, want to make use of tags each time a release is made. This will clearly indicate in Git the exact point at which the release cut was made.