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:
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
All features to be released or tested by QA are merged to a branch, lets say pre-develop
Verified features are cherry-picked to develop
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?
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:
Here we can see duplicate commits with rebase
Workflow 2
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:
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.