Background

At work we've been trying to find a new workflow. We currently follow git-flow pretty closely. We don't have release branches; we just merge develop directly into master once we feel like it's well tested enough. When we have a hotfix, we independently merge it into both develop and master.

One of the approaches we've been talking about is that instead of merging develop into master, we instead cherry-pick develop's commits into master. After a few cherry-picks, we deploy it and that's our release. Alternatively we could cherry pick from develop to a release branch (based on master), then merge into master.

At first I am personallywas opposed to this plan. It doesn't feel like idiomatic git. I like merging, because then youit would flatten the history out. And, we merge using the --no-ff option, meaning we can revert an entire "branch" (we use --no-ff in git). It keeps the history more clearfeatures if needed. With cherry-picks itThis would just look like a straight line with no branchesbe lost as well.

Other that that though, I can't really think of any reasons this would be a bad idea. At the same time I can't see any benefits to this approach. But I'm just a mid-level engineer with only a fewless than 10 years of professional experience. So I'm really interested in hearing people's experiences / thoughts about this.

Question

Are there benefits to cherry-picking instead of merging? And is there anything that we would lose by using this approach over traditional merging?