Given the following scenario:
- the main development branch is
develop - a feature branch (
ffor short) is created fromdevelop - a pull request is opened for the implemented feature
- the new feature should land in the new release but a release branch is created from
developbefore the feature is reviewed and merged - the PR gets reviewed and merged
After the f branch is merged into develop we should create a PR to the new release branch.
P.S. f branch is rebased over develop
We decided to go with a new branch from the release branch and just cherry pick the commit that we wanted. But it was because we were in a hurry and the commit was only 1. I am still wondering if there is some other easier way to do this.
What do you think will be the best and easiest way to do it?
Top comments (2)
The correct solution is to not back-merge features into a release without cutting a new release. The best way to achieve that is to remove any pressure to ensure that feature X is in release Y, probably by just not promising that a given feature will actually be in any given release (or delaying the release until the feature is ready if you don't have a fixed release cycle).
If you really have to do this, there are two approaches I've seen that work well for it:
In both cases, you should test thoroughly before actually putting the resultant branch into production, and ideally cut a new release once you're ready to put it into production.
Sounds good and makes a lot of sense. I don’t have the whole context about the releasing yet. But when I do and see if this is feasible solution, I will definitely suggest this one.
The rebasing was the other thing that we think of but didn’t go with it.
Wondering what should happen when we have merged feature needed in release, another one but not needed, and third one that is needed 🤔 Maybe then there is no chance to just make a new release branch.
Thanks for sharing your thoughts. : )