Handle git branching for test and production

When working with git (flow) and having a stage/test environment where the customer are doing their reviews of the things developed what is the best way of handling features that aren't approved along with features that are?

Consider the scenario that several developers working with different features in a sprint or in a continuous workflow. The features need to be reviewed by the customer and for the features to be able to be reviewed in the stage environment they have to be merged into the dev branch and deployed.

If, let's say, two features have been developed, considered done by the development team and been pushed to dev. The customer reviews them and approves ONE of them. But now the customer wants to release the approved feature to production. The dev branch is now "polluted" by a not approved feature code that can not be pushed to production.

What is the best way to handle such a scenario? Of course in reality it's more complex. Is cherry picking a solution or should the overall process and handling of branches be reconsidered?

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.

I think the right way here is:

• production (...)
• master (the dev branch)
• feature123
• feature234
• feature345
• feature[number]

If you can, provide a feature[number].example.com domain to the customers. So you can show all the feature before the merge in master branch. If a feature is refused, it must never be merged in master. If feature is accepted, it must be merged.

A good alternative is also a "staging" domain where to deploy code when it needed. Suppose your customer needs to see feature42, ... just deploy feature42 to customer.example.com domain.

Where to develop new feature?

feature[number] branch

Where to show new feature?

feature[number].example.com

Where to see next sprint code (master) at work?

next.example.com

or

master.example.com

Where to see production code?

www.example.com