Handle git branching for test and production

Question

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?

Realgar

If the dev branch contains everything that will be promoted to production, then a new feature cannot be pushed to dev for customer review. The customer needs to be reviewing the features while they still live on the feature branch to prevent a "polluted" dev branch. – Gobioid

But if the customer has no way of handling feature branches then the things to be reviewed needs to be put on the test environment manually feature by feature. And a new feature cannot be reviewed until the current one has been reviewed which make the overall process very slow – Realgar

Answer 1

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.

Decisive

Yes, this looks like the way to solve it. Gonna try this out and try to understand the workflow of it but it surely addresses the problems in the gitflow workflow – Realgar

@Realgar yes: the main point is: merge your topic/feature to an develop/integration branch, then merge that same topic/feature to a release branch. Don't try to merge your integration branch directly to the release one. – Decisive

@Raman Thank you for all your work around Gitworfklow! I referenced it many times over the years. – Decisive

@Decisive Thank for you work. I'm referencing Gitworfklow like you. But I have a question that I hope you can answer me. Does it mean that if a conflict occurs when merging/PR a feature/topic branch, will I have to fix the conflict twice? 1 when merging feature branch into Develop and 1 when merging it into Master. If that's the case, is there any way to cut them down? – Earpiercing

@DinoThunder Not always, but that can happen, if the same concurrent change is added to the target branch by two feature branches. git rerere can help in that case to mitigate the merge conficts resolution. – Decisive

@Decisive I understand what git rerere can do. But in my example, should I rebase master into the feature branch and fix the conflicts before merging it into Develop? – Earpiercing

@DinoThunder No, rebasing a long-lasting branch (like master) is not considered a good practice. What you do is rebase your feature branch on top of master, before merging it (trivially) to master. – Decisive

Answer 2

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

Lipolysis