GitFlow: Properly Testing Release Branches & Master

Question

I have been looking for a good branching model in git and found GitFlow would fit our development environment pretty well. However, one outstanding question is how and where to test our releases.

Release branches sound like a place to run all of the regression tests prior to the release. However, release branches are then merged into master, tagged, and that is what finally goes out to production. What happens if there are merging conflicts from release branch to master? Sounds like master needs to be completely re-tested (which could be costly). Even if there are no conflicts, is it safe to simply push that merge to production, or is there a need to run additional basic smoke tests?

Answer 1

After carefully tracing the GitFlow diagram, I convinced myself that there should never be any conflicts when merging into master (that is if the process is strictly followed). The reason, is because of the timeline:

1. Develop branch is created from Master
2. Features are committed on Develop branch
3. Release branch is created (which includes all the commits from Develop so far)
4. Bugs are fixed in Release branch
5. When ready, the Release branch is merged into Master
6. Master must contain all of the commits from Develop + Release branches. Conflicts should not occur because there was nothing done on Master after Develop branch was created (that's the only way conflicts would happen). In addition, the code at this point should be identical to the latest commit on the Release branch, which is means there is no need for additional testing.

I simplified the GitFlow diagram to convince myself of this: