Git / Subversion 中的功能向后移植

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

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

  然后开发继续进行并几个功能分支被合并到master/trunk（它们稍后将成为即将推出的一部分release-2.1.x).

• 现在，在某个时候另一个功能（即，critical-feature）被开发并合并回master/trunk。我们意识到这个功能非常重要，我们必须将其向后移植到release-2.0.x.

这是所描述案例的一个小伪图解。请注意，顶部的所有内容都会带来树之间的差异release-2.0.x和当前的master/trunk and 导致合并问题（否则我可以简单地合并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 into master/trunk什么时候完成？或者甚至可以作为一组cherry-picks对于中的每个提交critical-feature branch?

• 您能为冲突解决程序提供一些建议吗？如果当前之间的差异应该怎么办release-2.0.x and master/trunk如此巨大，以至于“天真的”向后移植会由于代码重构和缺少功能或功能而导致大量冲突API，这是在之后添加的release-2.0.x?

• Does Git or Subversion除了标准合并或挑选方法之外，还有其他具体内容可以为此例程提供吗？我猜可能是rebasing当冲突数量巨大时，这不会有帮助，但是，显然，我可能是错的。

向后移植的所有想法features对我来说看起来很糟糕。仅应向后移植关键且非破坏性的更改。对于功能和改进，您必须创建新分支并开始稳定期。

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