18

I am trying to introduce Git flow to my team. We are a fairly small team and quite agile. We want to release once a day and this means we have limited time towards testing all the changes in the day. Business team wants to be able to control the features that are getting released although its not ideal.

Git flow doesn't seem to accommodate this very well. After cutting a release branch from develop what is the best way to merge selected features to master. Is cherry picking the only option? Is there a better way?

ROMANIA_engineer
  • 54,432
  • 29
  • 203
  • 199
dark_src
  • 486
  • 5
  • 11
  • We are in the same boat at the moment, and are experimenting with the idea, to instead of merge, we would fork off a releaseXYZ branch from master (master is latest stable deployed to prod at all times), and use squash merges to pick individual feature branches into the release. We also need to test everything in dev though, and we only have one envi where we can deploy, so into dev we also continuously squash merge all feature branches, so dev can act as an experimental playground "all-in". So far this is the plan, since squash does not create a merge commit, so source branch stays clean – seekingtheoptimal Nov 19 '20 at 10:41

2 Answers2

19

The standard git flow handling is not ideal if the business team wants to control which features are in the next release. But you will have the same problem with other branching mechanisms.

The default structure for git flow is that you create a feature branch for each new feature. Once you have finished building (and testing) the new feature, you merge the branch back into your develop branch and then remove the feature branch. Then the feature will be included in the next release.

If a feature should not be included in the next release, you should not merge the feature branch back into the develop branch. That is the best way to make sure it will not be included. It also prevents other developers from creating code that uses (or otherwise requires) the new feature.

I would not recommend cherry-picking. First, a feature can (and frequently will) have multiple commits and it is easy to forget one. Second, if feature B uses code that was added in feature A, and management wants to release feature B without releasing feature A, you're likely to find that feature B is broken. And those dependencies are not always easy to spot.

It makes sense that management wants to prioritize new features, but each feature should be merged back into the develop branch soon after it has been completed (and tested).

Arjan
  • 9,784
  • 1
  • 31
  • 41
  • 1
    > But you will have the same problem with other branching mechanisms. True, this is not something that source control should manage. [Release Toggles (aka Feature Flags)](https://martinfowler.com/articles/feature-toggles.html#ReleaseToggles) are more suited for this purpose – janv8000 Jun 27 '18 at 07:42
0

If each feature has its own branch, simply merge that feature branch.

aragaer
  • 17,238
  • 6
  • 47
  • 49
  • hmm, how does this answer help solve the issue the user mentions about being able to select what features are actually released? – pal4life Feb 02 '15 at 20:58
  • `git checkout master; git merge feature1 feature2 feature3 feature4` - isn't it what is needed? You select which features to release by merging those branches. You don't release a feature which is not merged to master branch. – aragaer Feb 03 '15 at 05:21
  • So you are suggesting just merge in master the feature that is planned to be released and leave the feature that is not to be released inside the feature branch only? – pal4life Feb 03 '15 at 23:13
  • Basically yes. For each feature you want to include into release, merge feature branches into release branch. Then merge release branch into development branch. It might also be handy to rebase all other features to be on top of current development - now you have "new" feature branches growing from latest release point and you can delete "old" feature branches if you don't need them. – aragaer Feb 04 '15 at 08:10