I'm attempting to work out the best way in which to select a subset of commits from one branch to another with minimal affect on history (such as duplication of commits) for my particular workflow. Here's a description of my workflow, plus the scenario I'm attempting to use it in.
Workflow
master: Represents what's currently on the production servers.
develop: The code on the production servers, plus the latest changes that have been code-reviewed. Barring any problems, develop will be merged to master when the next release to production is performed.
feature-x: Branches for new features, taken from the head of develop. Pull-request made to develop, merged when it passes code-review.
Scenario
feature-1: is developed, passes code-review and is merged to develop.
feature-2: is developed, passes code-review and is merged to develop.
feature-3: is developed, passes code-review and is merged to develop.
Client decides feature-2 should be released without feature-1 and feature-3. feature-2 is a stand-alone change, i.e. it does not depend on anything introduced in feature-1.
I now need to get feature-2 in to master, without feature-1 or feature-3.
Suggested approaches
If I attempt to do a separate pull-request of feature-2 into master, then this will also release feature-1, as feature-1's commits are present in the feature-2 branch.
If I attempt to git cherry-pick
the commits from feature-2 into master, the commits will be duplicated when develop is next merged to master (i.e. when the next release occurs). Testing this with a trivial example merged cleanly, but git log
displays duplicate commits for anything included in the feature-2 branch.
Are there any alternatives? I can live with a slightly untidy history in this instance if there's no way around it, but the ideal solution would avoid duplicate commits. I'd also like to avoid rebasing master or develop, due to the fact that there will potentially be other feature-x branches active when this happens.
Any help appreciated.