git - Git/Subversion 中的特性向后移植

Question

使用 Git 或 Subversion 实现以下工作流程的首选方法是什么 (我对 Git 版本，但比较肯定会有用):

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

  The development then continued and several feature branches were merged into the master/trunk (they will later become the part of the upcoming release-2.1.x).

• 现在，在某个时候开发了另一个功能(即 critical-feature)并 merge 回 master/trunk。我们意识到此功能非常重要，因此我们必须将其反向移植到 release-2.0.x。

---

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

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

• Git 或 Subversion 除了标准的 merge 或挑选方法外，是否为这个例程提供了特定的东西？我猜想 rebase 在冲突数量巨大的情况下不会有帮助，但显然，我可能是错的。

Answer 1

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

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