Git:为发布选择更改的子集

Question

我正在尝试找出最佳方法，以选择从一个分支到另一个分支的提交子集，同时对我的特定工作流程的历史影响最小(例如重复提交)。以下是对我的工作流程的描述，以及我尝试在其中使用它的场景。

工作流程

ma​​ster:代表当前在生产服务器上的内容。

开发:生产服务器上的代码，加上经过代码审查的最新更改。除非有任何问题，否则开发将在下一次发布到生产时 merge 到主控中。

feature-x:新功能的分支，取自 develop 的头部。提出开发请求，在通过代码审查时 merge 。

场景

feature-1: 已开发，通过代码审查并 merge 到开发。

feature-2: 已开发，通过代码审查并 merge 到开发。

feature-3: 已开发，通过代码审查并 merge 到开发。

客户决定 feature-2 应该在没有 feature-1 和 feature-3 的情况下发布。 feature-2 是一个独立的更改，即它不依赖于 feature-1 中引入的任何内容。

我现在需要掌握feature-2，没有feature-1 或feature-3。

建议的方法

如果我尝试对 feature-2 进行单独的 pull-request 到 master，那么这也会发布 feature-1，因为 feature-1 的提交存在于 feature-2 分支中。

如果我尝试 git cherry-pick 将 feature-2 中的提交提交到 master 中，则当 develop 下一次 merge 到 master 时(即下一个版本发布时)，提交将被复制。使用干净 merge 的简单示例对此进行测试，但是 git log 显示 feature-2 分支中包含的任何内容的重复提交。

还有其他选择吗？在这种情况下，如果没有办法解决的话，我可以忍受稍微凌乱的历史记录，但理想的解决方案是避免重复提交。我还想避免对 master 或 develop 进行 rebase ，因为发生这种情况时可能会有其他 feature-x 分支处于事件状态。

感谢任何帮助。

Answer 1

使用您建议的第一种方法，稍作修改:只需从最后一点创建功能分支 develop 并 merge 到 ma​​ster。

在下面的场景中，LM commit 表示从 develop 到 ma​​ster 的最后一次 merge ，LC 最后一次 merge 开发的 promise 。

----o---------o-----------o------------o--------> master
   /         /            /           /
--o--o---o--o---o---o----o-----o-----LM---o---o---LC------> develop

而不是从上次提交创建一个新的功能分支:

----o---------o-----------o------------o--------> master
   /         /            /           /
--o--o---o--o---o---o----o-----o-----LM---o---o---LC------> develop
                                                   \
                                                    ---------> feature_branch

从上次 merge 创建功能分支:

----o---------o-----------o------------o--------> master
   /         /            /           /
--o--o---o--o---o---o----o-----o-----LM---o---o---LC------> develop
                                      \
                                       ------------------------> feature_branch

通过这种方式，您可以从没有其他"new"功能的功能分支创建 pull 请求。