We are developing multiple features in a separate branches, like each feature in one branch, then merging them to a develop branch for testing purposes. We have a release day every week, so are releasing a few of the features only to master branch. How can we pick only those few features to be merged to master without getting the code of other features that are not ready for release?
Asked
Active
Viewed 111 times
3 Answers
0
There's several way to do this with Git, but one way would be to cherry-pick only the features you want into your release branch (which seems to be master from your description). For this, I recommend all your features/fixes are squashed/merged into the feature branches ahead of time, so that choosing which hashes to cherry-pick will be easier.
See more details in this other question: What does cherry-picking a commit with git mean?
mjuarez
- 16,372
- 11
- 56
- 73
0
There are at least a couple options for this problem:
Option 1 -- Merge features one by one
Merge the feature branches individually directly into master (ignore develop when merging to master). This approach should work no matter what your process. However, you run the risk that develop gets "ahead" of master and contains unverified changes. You can mitigate that somewhat by reverting failed changes in develop or having freeze periods where develop must reach release worthiness.
As mjuarez pointed out, you can alternatively use cherry-pick to achieve a similar outcome -- but only if your features can be confined to individual commits.
Option 2 -- Merge serialized features
If your features are validated or accepted serially, that is in the same order they are merged to develop, then you can merge to master the specific commit from the develop branch which contains the changes you want.
For example, if develop contains:
- feature a with hash aaa (oldest)
- feature b with hash bbb
- feature c with hash ccc (newest) = develop HEAD
...and you only want to validate/promote features a and b for release to master, then you can merge the commit bbb to master.
The biggest advantage to this is you do not risk piling up unverified changes in develop.
Other
Besides these you may want to consider other branching approaches altogether.
https://nvie.com/posts/a-successful-git-branching-model/
https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
Will
- 6,601
- 3
- 31
- 42
0
Here is an approach we do in our team. Please see if this fits your requirement. Once a feature is merged to develop and QA tested, we create a release branch(Release_XXX) from the Develop. The code migrates to production from this release branch. Once the production migration is completed, we migrate the code to master from this release branch only, this makes sure you are only migrating your tested feature code to master.
BipinR
- 473
- 7
- 19
-
assume is that we are developing 10 features and after complete testing cycle we can release only 3 features based on the business owner approval in this case if we merge the code from develop branch to release branch its will merge all code including the unwanted features , i am looks for a way to allow me to select cretin features and deliver them to release branch – Amr Youssef Nov 05 '18 at 09:04