4

From the following snippets taken from here

finished features and fixes are merged back into the develop branch when they’re ready for release

From what I understand this would mean that features are merged to develop when developers are confident with their work.

When it is time to make a release, a release branch is created off of develop

And in this line, features in the develop branch are expected to be released.

Above is all fine until a feature is decided to be not "ready" for release as tested by QA or maybe it's almost the release date that the said feature can just be moved to the next release.

I know doing a git revert could help on this. I happen to experience this a long time ago (I already forgot what I did during that time though) but I've been using an experimental custom workflow which prevents cases like this.

the experimental custom workflow Worlflow 1

The flow I'm experimenting is almost the same as gitflow except the part were "features are merged to develop". In this experimental workflow it is replaced with "verified features to be working are merged to develop"

The flow becomes like this:

  1. All features to be released or tested by QA is put (not merged) in a features-to-test branch (develop branch + all features to be released)
  2. Verified features are merged to develop
  3. New feature branches are created from develop

It's working fine for me but there is a minor problem. It creates duplicate commits on every rebase. I've tried cherry-pick, merge (with ff) and pull --rebase but all the same outcome.

There's another method that I'm planning on testing to avoid the duplication of commits on every rebase but I think it will also have another set of problems.

It's almost the same with the workflow above

Workflow 2

  1. All features to be released or tested by QA are merged to a branch, lets say pre-develop

  2. Verified features are cherry-picked to develop

  3. New feature branches are created from pre-develop since it contains all the features (bleeding edge)

It's not perfect but it makes my life a bit easier, for now at least.

Thoughts on this? Do you have better alternatives that will address this scenario?

Dev
  • 1,592
  • 2
  • 22
  • 45

1 Answers1

0

Let's see how new changes are moving between branches

Regular gitflow:

  • develop -> feature

  • feature -> develop

  • develop -> release

Workflow 1:

  • develop -> feature

  • feature -> feature-to-test

  • feature-to-test -> develop

so from feature to develop it goes:

  • develop -> feature -> feature-to-test -> develop

Here we can see duplicate commits with rebase

Workflow 2

  • pre-develop -> feature
  • feature ->cherrypicked-> develop

This seems kind of weird, I haven't seen this approach before. It might work, I am not sure.

However I think the best is to stick to the classic git flow and if you need to remove feature branch, use revert. Answers from these questions can help as well:

https://softwareengineering.stackexchange.com/questions/295202/what-happens-if-a-feature-merged-into-develop-is-postponed-by-management

Git-Flow undo a finished feature branch

vanillaSugar
  • 523
  • 1
  • 5
  • 14
  • I've been thinking about it but how will revert handle commits that are spread out. For example the history will become like this: `feature_1_# > random_develop_commits > feature_1_# > random_develop_commits > feature_1_#` and then I have to revert all `feature_1` commits. I would have to do revert each commit then, right? – Dev Jun 01 '18 at 09:23
  • There's this [skullcandy's workflow](https://www.endpoint.com/blog/2014/05/02/git-workflows-that-work) which I think will work in our case but I can't seem to figure out the part `changes that have been approved by the business owners in QA got merged into master and released`. It seems a `merge` is done twice. – Dev Jun 01 '18 at 09:54