Question

使用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角度执行功能反向移植的最佳方法是什么？
这是否应该作为解决冲突冲突的相应merge分支的简单critical-feature来完成？
或者这应该作为提交的cherry-pick来完成，它会在critical-feature合并到master/trunk时完成？或者甚至可以为cherry-picks分支中的每个提交设置一组critical-feature？
您能为冲突解决程序提供建议吗？如果release-2.0.x和master/trunk之间的当前差异如此巨大，那么应该怎么办？由于代码重构和缺少功能或API，“天真”的向后移动会导致大量冲突，这是在release-2.0.x？
除了标准合并或挑选方法外，Git或Subversion是否具有针对此例程提供的特定内容？我想，如果冲突数量很大，那么 rebasing 将没有用，但显然，我可能错了。

Answer 1

这取决于。如果关键功能相对简单和小巧，你可以做几个樱桃选择。但是，当然它可能会导致很多合并冲突，因为该功能的实现可能会使用重构的代码。但是，据我所知，这将是最简单的解决方案。只有SVN的解决方案。

但是，此解决方案并未反映历史记录图表中的操作，而是令人困惑。

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

重新定义的功能方法的好处是，如果你发现它有一个错误，你可以在功能分支中修复它，并轻松地将修复程序合并到发行版和主分支中。

当然，重新定位可能会导致很多冲突，但这意味着没有简单的方法将该功能反向移植到{{1}}。也许再重新实现它会更容易。

Answer 2

反向移植功能的所有想法对我来说都很糟糕。只应向后移植严重和非破坏性的变化。对于功能和改进，您必须创建新的分支和启动稳定期。

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

Answer 3

我已经开发了一些专门用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的rebased建议，除了后向移植过程更加结构化，并且通过使用git notes，您可以获得几个方便的额外功能，包括描述该过程的所有元数据在多次运行中保持不变git cherry-menu。

当然，如果你只有一些提交后退，kan是正确的，你可能只是直接挑选。

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

反向移植功能的所有想法对我来说都很糟糕。只应向后移植关键和非破坏性更改。对于功能和改进，您必须创建新的分支和启动稳定期。

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

功能在Git / Subversion中向后移植

问题：

3 个答案: