gitflow branching strategy - multiple releases

Question

currently, we are using the GitHub flow (feature branching) strategy. However, with that, the problem is sometimes features are queues in for releases i.e.

1. I have my featured merged in development (or master, we have only) branch and deployed to Test Environment for testing.
2. Meanwhile, we want to develop or fix some high priority bugs/features. I can't do that without reverting earlier code from develop branch.

To solve this issue, I am trying to implement GitFlow Branching Strategy. However, I am thinking that very similar problem as above may arise as mentioned below.

• I created a new feature branch, done my development and merged to develop
• we merged few more feature to develop
• Cut out a new release branch (let's called release-A) and then deploy it to Test Environment for testing.
• meanwhile this feature is being tested, new feature request came which has a high priority
• Now if I branch out of latest develop, it has other features (release-A) which I don' t want to deploy to prod. (or merge with the master)

Questions:

• Rather, than branching of lastest, develop branch, should I branch from the commit has which is in PROD?
• if so, should I create a release from the feature branch?
• how to deploy this in Test so that testing or both (release-A and this new feature can happen in parallel). The latter point is no so important.

Note: I am using Microsoft Azure Data Factory, and so I need to merge some changes to develop branch ( related to Azure Data Factory) otherwise I won't be able to publish those changes (won't be able to create ARM template to deploy to other environments)

Answer 1

Note: suggestions down below will work as long as release-A and upcoming high priority updates do not overlap each other (change same file content). If both are updating same piece of code go to (*)

Rather, than branching of lastest, develop branch, should I branch from the commit has which is in PROD?

That's a great idea, as PROD seems to be the only place free of release-A code updates.

how to deploy this in Test so that testing or both (release-A and this new feature can happen in parallel). The latter point is no so important.

So based on previous question, you cut new feature branch "B" based on PROD one, create commits for high priority feature and merge to develop branch. Next you can have same feature branch "B" merged to Test environment in order for release-A and this new feature B testing to happen in parallel. Finally when testing feature B is done, you can merge same feature B branch to PROD.

*) I would revert release-A on Test as you suggested, then merge new feature B, release and finally undo the revert on Test environment (integrating with feature B if needed). To overcome this from happening again you need to have some extra environment, like demo, where you can validate these hot-fixes without interfering with in progress releases.

Answer 2

Have you thought about using cherry pick to picking specific commits from develop branch to the release branch? so unwanted features can be avoided.

Checking out the release branch from develop branch when you are preparing the release.

Some new features/bug fixes can still be merged to develop, but you can cherry pick what features you want to include in your release.

See visualised diagram

Answer 3

Now if I branch out of latest develop, it has other features (release-A) which I don' t want to deploy to prod

The problem is that you have one develop for multiple releases: that "integration" branch (in which you integrate) multiple feature branches, becomes messy because you end up with "features you don"t want"

It is best to have multiple integration transient branches, that is "develop" branches created just for making a specific release (once it is done, you create a new integration/develop release to integrate a new set of features, or older feature branches that did not make the cut for the previous release)

A good example of that approach is the gitworkflow (one word).

Answer 4

Check https://nvie.com/posts/a-successful-git-branching-model where the branching model is nicely visualized.

If your new high priority feature should preempt the ReleaseA and should go straight to production, I would consider it a hotfix and therefore I would create a hotfix branch from the latest production version. Develop the feature there and test it and then merge straight into he master and into the development branch.

Feature branches are temporary branches that get branched off and into development only. So you would never create a release branch from a feature branch or merge feature branches straight into production/master.