handling release branches in gitflow

Question

The company I work for is using gitflow.

We follow a branch-per-feature approach where individual features are implemented, tested and then PR'd into develop. When it comes time for a release we create a release branch off develop - we trigger a build on the release branch and deploy this to a TEST environment. There might be some integration defects due to the multiple feature branches that were merged into develop. These are resolved directly against the release branch. Once we're happy with the state of the release branch we deploy (the exact same build that was signed-off by QA) to PROD.

At this stage we need to get our release branch code back to develop and into master, which are both protected branches. Assuming there were some commits against the release branch, we need to do 2 PRs ie one for release->develop and one for release->master.

Couple questions:

1. How do people review commits directly against a release branch? We could PR back to develop before the actual release, but this seems a bit out of order to me.
2. How do people approach gettting a release branch merged into develop AND master. The PR to develop would just be commits that were made directly against the release branch, while the PR to master would also include all the features that were already PRd into develop. The PR to master seems a bit obsolete.

Thanks.

Answer 1

tl;dr: Ideally you should not need a code review when performing routine Git Flow branch merges. Instead you would make sure all commits into the Git Flow shared branches are code reviewed. Note this solution answers both of your questions.

Details: In your example, merging release into master , or release into develop (ideally) would not need human intervention, and could theoretically be automated ¹ . In order to achieve that though, you do need to code review all commits that go into release , meaning you need to tweak this part of your workflow:

There might be some integration defects due to the multiple feature branches that were merged into develop. These are resolved directly against the release branch.

If you create feature branches off of release and PR them into the release branch with a normal code review, then later when it's time to merge release into another shared Git Flow branch you can be assured that all code on the release branch has already been code reviewed, and the merge becomes a routine merge that doesn't necessitate an in-depth review.

Many Git SCM tools have the concept of Protected branches, which require a PR be used in order to merge code into them. The recommendation here is in addition to protecting develop and master , you should also protect your release and hotfix branches.

Tip: when completing a release branch, Git Flow recommends merging the release branch into both master and develop . However, there is a slightly more efficient mechanism which achieves the same state but has some added advantages. The tweak is to first merge release into master , and then merge master into develop . The benefit of doing this is the new merge commit on master will also be on develop , which means develop is "ahead" of master . When it comes time to merge the next release branch into master it would be fully up to date from a commit ID point of view, meaning you could do a fast-forward merge. Of course you'll still merge into master using --no-ff like Git Flow recommends, but knowing that you could fast-forward tells you with certainty that the state of master after the merge is identical to the release branch you tested. If you don't do it this way, you have to compare the states to make sure you aren't about to blow over a hotfix on master that you forgot to merge back into release or develop . Another minor benefit is that without doing this, if you have multiple releases in a row, the first time you have a hotfix you'll be merging a bunch of old merge commits from master into develop for the first time, and it's sort of confusing to see that.

---

¹ Git Flow shared branch merges can usually be completed automated. Only in the case where there are non-deterministic merge conflicts would a human need to get involved. An example of non-deterministic conflicts might be when merging release or master down to develop , where certain files have changed in both branches after the release branch was created. Note that some conflicts could be considered deterministic and can still be auto-resolved with logic, such as version files that are modified in both branches and the resolution mechanism is known beforehand.