Issue merging Git Feature branch into "Beta" branch (after it has already been merged to "Develop" branch)

Question

We have a standard web project and maintain 3 core branches for this project: Master, Beta, and Develop. Here is a summary of the process/workflow that we use:

(1) A new feature/update is requested so we create a new Feature branch.

(2) A commit is made for the new Feature branch and the Feature branch is merged into the 'Develop' branch; the 'Develop' branch is then published to a testing environment to be tested.

(3) Once the new feature is tested/approved, a new pull request is made in the same Feature branch; this new pull request is meant to be merged into the 'Beta' branch.

The 'Beta' branch has all of our "ready-to-go-live" features: in fact, we publish the 'Beta' branch directly to the production environment and when that is ready we immediately merge the 'Beta' branch to the 'Master' branch....by doing this, the 'Master' branch is always a copy of the code that is on the production environment.

The problem: in step 3 above, when we try to merge the new Feature branch into the 'Beta' branch, the pull request includes ALL new commits that have been merged into the 'Develop' branch.

Example: 5 feature branches are individually merged to the 'Develop' branch (branches are labeled 1, 2, 3, 4, and 5). All 5 are tested, but there are bugs with the first 4. So branch "5" is approved and we try to create a pull request for that Feature branch and merge it to 'Beta'....but when we do that, the pull request includes all 5 feature branches....not just the commit for branch "5".

We MUST be doing something wrong! What can we do to fix our process/workflow?

Answer 1

(3) Once the new feature is tested/approved, a new pull request is made in the same Feature branch; this new pull request is meant to be merged into the 'Beta' branch.

The 'Beta' branch has all of our "ready-to-go-live" features: in fact, we publish the 'Beta' branch directly to the production environment and when that is ready we immediately merge the 'Beta' branch to the 'Master' branch....by doing this, the 'Master' branch is always a copy of the code that is on the production environment.

The problem: in step 3 above, when we try to merge the new Feature branch into the 'Beta' branch, the pull request includes ALL new commits that have been merged into the 'Develop' branch.

No, that does not make sense. If that happens you have omitted important information such as:

• Each new feature branch is branched off of another branch. Which one, development? Then it is clear that whatever development commits are in the history of a newly created feature, will also be merged into the beta branch. Git history is a directed acyclic graph, each commit pointing to one (normal commit) or multiple (merge commit) parent commits.
• In order to make features merge cleanly into develop, maybe the feature branches are rebased onto development regularly or maybe the feature branches get refreshed by merging in the latest develop, both of which makes much sense and I advocate it. But in this case also their history contains all the history of develop at the time of merging/rebasing.

In each of these cases your workflow is fundamentally broken and cannot work with regard to your idea of a beta branch. So if you want to avoid cherry-picking (bad! bad! bad!) how can you achieve what you want to do? There are some basic options:

1. Feature toggles: ugly. I would stay away from it whenever possible. The best way to inactivate a feature in any branch is not having the corresponding commits on that branch in the first place.
2. Work cleanly: good. Refrain from merging back untested/unaccepted features to develop. Only merge them when they are done (as in "definition of done") and accepted by the client. Make sure you set up an environment enabling your clients to directly test on feature branches instead of mashing it all up onto a beta branch. This way whatever gets on development is inherently ready for production and you do not need the beta branch anymore. Unfinished work is never to be merged into a higher-level branch. This is what GitFlow is all about and it works. Even if you do not use GitFlow in its full glory but just master, develop and feature branches, the validity of my statements holds. I have worked like this in many projects and it works beautifully. Besides, if you think you need another branch to integrate features onto for future releases, create a new "next_release" or "future" branch for them and merge them to that branch, not onto develop. Then regularly refresh future from develop because you also want your features from the current release in the future release, but not vice versa. I hardly believe that this additional step will be necessary though.

Answer 2

That's the way git works. You'll need to create separate branches for each feature.