Git / Subversion中的功能反向移植 [英] Feature backporting in Git / Subversion

问题描述

通过 Git 或 Subversion 来实现以下工作流程的首选方式是什么对 Git 版本有更多的兴趣，但比较肯定会有用）：

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

  
  

  开发工作继续进行，几个功能分支被合并到 master / trunk （他们稍后将成为即将发布的 release-2.1.x 的一部分）。

  
  




• 现在，在某个时候开发了另一个功能（即 critical-feature ），并将其合并回到 master /躯干。我们意识到这个特性非常重要，我们必须将它恢复到 release-2.0.x 。

>

---

下面是所描述情况的一个小赝图。请注意，顶部的所有内容在 release-2.0.x 和当前 master / trunk 和导致合并问题（否则我可以简单地合并 critical-feature 并避免写下这个问题：）

 （从2.0.x开始添加的功能，
不应该被反向移植）
 ^ ^ ^ 
 | | | （在master / trunk中完成代码重构
 | | |）
 \ | /（*）（*）（*）
 ------------------------------------ -------------------> master / trunk 
 | | 
 | | 
 | | 
 \ release-2.0.x \ critical-feature 
（应该是backported）
  

问题：

• 从执行功能回溯的最佳方法是什么？ VCS 透视图




• 这应该作为一个简单的 merge 相应的关键特征分支带冲突解决冲突？




• 或者应该这样做提交的 cherry-pick ，它将 critical-feature 合并到 master / trunk 何时完成？或者甚至可以为 critical-feature 分支中的每个提交提供一组 cherry-picks ？




• 您能否为冲突解决程序提供建议？如果当前 release-2.0.x 和 master / trunk 之间的差异如此巨大，天真backporting会导致由于代码重构和缺少功能或 API 而导致的大量冲突，这些冲突是在 release-2.0.x ？




• 是否 Git 或 Subversion 有特定的东西提供这个例程，除了标准合并或樱桃采摘的方法？我认为 rebasing 在冲突量很大的情况下不会有帮助，但显然我可能是错的。




>

解决方案

支持功能的所有想法对我来说都是破灭的。只有重要的和非破坏性的改变才应该回溯。对于功能和改进，您必须创建新的分支并开始稳定期。

检查Apache Subversion项目本身使用的发布过程：
https://subversion.apache.org/docs/community-guide/releasing.html#释放稳定性

What would be the preferred way to achieve the following workflow with either Git or Subversion (I have more interest in the Git version, but comparison will definitely be useful):

• Let's say we had a major release of the product recently and there is a specific polisihin branch called release-2.0.x.

  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).

• Now, at some point another feature (namely, critical-feature) was developed and merged back to master/trunk. We realize that this feature is so important, that we have to backport it to release-2.0.x.

---

Here is a small pseudographic illustration for the described case. Note that everything on the top brings in tree differences between release-2.0.x and current master/trunk and leads to merging problems (otherwise I could simply merge the critical-feature and avoid writing this question :)

    (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)

Questions:

• What would be the best way to perform the feature backporting from the VCS perspective?

• Should this be done as a simple merge of the corresponding critical-feature branch with conflict-resolving conflicts?

• Or should this be done as the cherry-pick of the commit, which merges the critical-feature into master/trunk when it's done? Or maybe even as a set of cherry-picks for each commit in the critical-feature branch?

• Could you advise something for the conflict resolution procedure? What should one do if the current difference between release-2.0.x and master/trunk is so huge, that "naive" backporting leads to a huge amount of conflicts due to code refactoring and missing features or API, which were added after the release-2.0.x?

• Does Git or Subversion have something specific to offer for this routine except standard merging or cherry-picking approach? I guess that rebasing won't be helpful in case when the amount of conflicts is vast, but, obviously, I might be wrong.

解决方案

The all idea of backporting features looks broken for me. Only critical and non-destructive changes should be backported. For features and improvements you have to create new branch and start stabilization period.

Check out release process used in Apache Subversion project itself: https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization

这篇关于Git / Subversion中的功能反向移植的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！