Handle git branching for test and production

That issue (dev branch polluted by “non-approved but already integrated” feature branches) is exactly what describe Raman Gupta in “How the Creators of Git Do Branching“.
(GitHub repo for this workflow: rocketraman/gitworkflow)

In your case (gitflow), you would need to revert the merge commit of the non-approved features before merging dev to release.

But the “gitworkflow” uses ephemeral branches, by opposition of gitflow:

GitFlow advocates having two eternal branches — master and develop

Both workflow (gitflow or gitworkflow) use “feature” or “topic” branches:

Topic branches are where all the current work is being done — one branch per issue, bug, or feature, and there can be many topic branches undergoing development at once.

A topic ends up merged into the branch “next” in gitworkflow.
However, a key difference is the next branch is never merged to master (as opposed to the eternal branch “develop” which is meant to be merged to master/release in gitflow)

Now that the topic has graduated to next, it can be part of a beta, or acceptance release. So every topic on next can now undergo a second round of stabilization, which is exactly the purpose of a beta release / acceptance testing environment.

However, note that with gitworkflow, we still have not committed (no pun intended!) to having this topic as part of our next release to production — it still has not been merged to master.
This is similar in concept to GitFlow’s release branch, but far more flexible and powerful, since master has no dependencies on next whatsoever, nor is next ever merged wholesale into master (unlike the corresponding GitFlow branches develop and release).

If next is not merged to master, how you graduate a feature to production?

Once a topic is judged stable enough to release, the topic graduates again and is merged to master (or perhaps maint), again with --no-ff to preserve the complete history of the topic branch.

Why is this better:

Note that in gitworkflow, unstable and stable development work is never mixed together on the same branch.

In contrast, with GitFlow I have two choices:

1. I can test my topic in isolation on its own branch, or
2. I can merge it to develop for testing.

Neither choice is appealing.

• The former doesn’t offer a true test of a topic’s stability when deployed together with other ongoing work, and
• the latter commits the topic to develop perhaps before it is stable.

Meaning:

In short, in GitFlow there is always an unsolvable tension between the desire to keep development work clean and isolated on a topic branch, and integrating topic branches with other work by merging them to develop to make them visible and testable and to check for conflicts.
Gitworkflow allows both goals to be achieved without sacrificing one for the other.