How to review and merge a big feature

Question

We are creating a new page on our website which will require overall ~5000 LOC. Now the problems here are:

1. How to get so many lines reviewed?
2. When to merge these changes to master for release?

How we currently solve these problems: We create a temporary Release branch in which everyone will merge their features related to this page. These individual features/pull requests are reviewed by peers. We also keep rebasing this branch with master after every release.

When this temporary Release branch is functionally ready to go live, we merge it in the next release branch which will eventually be merged to master.

Main question:

1. Are we right in maintaining this temporary Release branch merging features in it or is there some better way? On some websites it suggests to merge each small feature of new page to master and take it(keeping it hidden) and in last release you should make these features visible

I have read online but couldn't find the my problem listed elsewhere.

Some research:

Is it better to merge "often" or only after completion do a big merge of feature branches?

https://google.github.io/eng-practices/review/developer/small-cls.html

Answer 1

Merging a feature branch into master or dev should be a fast-forward merge, and thus should not require another review.

Any previous merges or new development should have been peer reviewed already against the feature branch.

What you call a "temporary release" branch is also called a "topic" branch or "feature" branch. This is a valid Git workflow, however you should not rebase public history. If this branch has been pushed to any remote, you should never rebase it, because this changes the shared history of the branch.

It is common to require multiple pull requests to get a feature ready for release. Developers create their branches from this common feature branch and issue a pull request to merge their branch into the feature branch. Your team will need to decide how often and when the master branch should be merged into the feature branch (or the "dev" branch is that is the branch you use to integrate work).

Our team has agreed upon a naming convention for these kinds of branches: topic/blog_post_comments or feature/blog_post_comments would work. Anything under topic/ or feature/ is known to be a "shared" branch where people create their own personal branches from the tip of these branches, and issue a pull request to merge back into that branch.

This does incur increasing overhead to keep the feature branch up to date with master or dev. The longer a branch lives, the more overhead is incurred by merges to keep that branch up to date. As mentioned in a comment you might investigate Trunk-based Development where you include or exclude code based on feature toggles. See Why I love Trunk Based Development (or pushing straight to master) for a good introduction.

With Trunk-based Development everything gets merged in to master. You will need a strong set of automated tests to verify the application keeps functioning properly as you develop or change features. You will also need a way to enable or disable code from entire classes to individual methods within a class. Doing this means you don't have to worry about your "temporary release" branch at all. Everyone creates short lived branches that get incorporated into master on a daily basis.