功能在Git/Subversion中向后移植

Question

什么是实现以下工作流的首选方法与任何Git或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并导致合并问题(否则我可以简单地合并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有一些具体的事情来提供该程序,除了标准的合并或挑肥拣瘦的做法？我想,再过当量将不会在情况下有益的,当冲突的量是巨大的,但是,很明显,我可能是错的.

Answer 1

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

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