2

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)

Gaurang Shah
  • 11,764
  • 9
  • 74
  • 137

2 Answers2

1

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.

Andreas_75
  • 44
  • 5
0

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).

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250