Git / Subversion 中的功能反向移植答案

【问题标题】：Feature backporting in Git / SubversionGit / Subversion 中的功能反向移植
【发布时间】：2012-08-21 09:17:17
【问题描述】：

使用Git 或Subversion 实现以下工作流程的首选方法是什么（我对Git 版本更感兴趣，但比较肯定会有用）：

假设我们最近发布了该产品的主要版本，并且有一个名为 release-2.0.x 的特定 polisihin 分支。

随后继续开发，几个功能分支被合并到master/trunk（它们稍后将成为即将推出的release-2.1.x的一部分）。
现在，在某个时候，另一个功能（即critical-feature）被开发并合并回master/trunk。我们意识到此功能非常重要，因此我们必须将其反向移植到 release-2.0.x。

这是所描述案例的一个小的伪图形插图。请注意，顶部的所有内容都会导致release-2.0.x 和当前master/trunk 之间的树差异，并且导致合并问题（否则我可以简单地合并critical-feature 并避免写这个问题:)

    (features added since 2.0.x, which
     should not be backported)
              ^   ^    ^
              |   |    |    (code refactorings done
              |   |    |     in master/trunk)
              \   |    /     (*) (*) (*)          
-------------------------------------------------------> master/trunk
      |                                          |
      |                                          |
      |                                          |
      \ release-2.0.x                            \ critical-feature
                                                   (should be backported)

问题：

从VCS 角度执行功能反向移植的最佳方法是什么？
这是否应该作为具有解决冲突冲突的相应critical-feature 分支的简单merge 来完成？
或者这应该作为提交的cherry-pick 完成，完成后将critical-feature 合并到master/trunk 中？或者甚至可以为critical-feature 分支中的每个提交设置一组cherry-picks？
您能为解决冲突的程序提供一些建议吗？如果release-2.0.x 和master/trunk 之间的当前差异如此之大，“幼稚”的反向移植会由于代码重构和缺少功能或API（在@ 之后添加）而导致大量冲突，该怎么办？ 987654345@?
除了标准的合并或挑选方法之外，Git 或 Subversion 是否有针对此例程的特定功能？我想 rebase 在冲突数量很大的情况下不会有帮助，但显然，我可能错了。

【问题讨论】：

标签： git svn merge merge-conflict-resolution feature-branch

【解决方案1】：

对我来说，向后移植功能的所有想法似乎都被打破了。只有关键的和非破坏性的更改应该被反向移植。对于功能和改进，您必须创建新分支并开始稳定期。

查看 Apache Subversion 项目本身使用的发布过程： https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization

【讨论】：

欢迎提出您的意见，但鉴于很多项目做向后移植功能，“不要那样做”并不是最有帮助的答案。跨度>

【解决方案2】：

我已经开发了一些专门用于使用 git 简化此过程的工具，上周我写了an extensive blog post 来介绍它们。特别是，该帖子中引用的 git cherry-menu 命令可以接受任意的向后移植提交列表，因此使用 git log 和您最喜欢的文本编辑器，您可以构建一个合理仔细选择的提交列表，这些提交构成了要成为的关键功能向后移植，然后运行类似：

git checkout -b release-2.0.y release-2.0.x
git cherry-menu cat commits-to-backport.txt

这类似于 kan 的 rebase 建议，除了向后移植过程更加结构化，并且通过在后台使用 git 注释，您可以获得一些方便的额外功能，包括描述该过程的所有元数据在多次运行中保持不变git cherry-menu.

当然，如果您只有少数提交要向后移植，kan 是对的，您不妨直接挑选。

不幸的是，我认为接受的答案有点自相矛盾：

对我来说，反向移植功能的所有想法似乎都被打破了。只有关键的和非破坏性的更改应该被反向移植。对于功能和改进，您必须创建新分支并开始稳定期。

因为创建新分支并开始稳定期仍然是向后移植。唯一的区别是您决定将向后移植的提交放入哪个分支！您可以将它们放入原始的 release-2.0.x 分支，或者从它分支出来的不同分支，就像我上面建议的 release-2.0.y 分支。后者通常更安全/更清洁（我想这是 Ivan 的观点），但这实际上取决于您如何组织存储库和分支。尽管如此，它仍然无法避免执行挑选和解决潜在冲突的需要。

【讨论】：

【解决方案3】：

这取决于。如果关键功能相对简单且小，您可以挑选几个樱桃。但是，当然它可能会导致很多合并冲突，因为该功能的实现可以使用重构的代码。但是，据我了解，这将是最简单的解决方案。也是 SVN 的唯一解决方案。

但是，这个解决方案没有反映历史图表中的操作，它会造成混淆。

在 git 中，rebase 的关键特性位于 master 的 merge-base 和 release-2.0.x 分支的另一个选项。它的字面意思是您应该使用旧代码重新实现该功能，这对于两个分支都很常见。在这种情况下，您可以合并重新定位的功能。如果您已经将该功能合并到主控，当您将重新定位的功能合并到主控时，它很可能会发生冲突（因为主控已经有这样的实现）。因此，您将解决冲突，但在大多数情况下，这很容易，因为更改应该几乎相同。

rebased feature 方法的好处是，如果您发现其中的错误，您可以在 feature 分支中修复它，并轻松地将修复合并到 release 和 master 分支中。

当然，变基可能会导致很多冲突，但这意味着没有简单的方法可以将该功能反向移植到release-2.0.x。也许重新实现它会更容易。

【讨论】：