9

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并导致合并问题（否则我可以简单地合并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我想在冲突数量很大的情况下，重新设置基准不会有帮助，但是，显然，我可能是错的。

4

3 回答 3

2

这取决于。如果关键功能相对简单且小，您可以挑选几个樱桃。但是，当然它可能会导致很多合并冲突，因为该功能的实现可以使用重构的代码。但是，据我了解，这将是最简单的解决方案。SVN 的唯一解决方案。

然而，这个解决方案并没有反映历史图表中的动作，它令人困惑。

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

rebased feature 方法的好处是，如果您发现其中的错误，您可以在 feature 分支中修复它，并轻松地将修复合并到 release 和 master 分支中。

当然，变基可能会引起很多冲突，但这意味着没有简单的方法将功能反向移植到release-2.0.x. 也许那时重新实现它会更容易。

于 2012-08-26T20:23:58.537 回答
2

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

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

于 2012-08-28T14:54:34.510 回答
2

我已经开发了一些专门用于使用 git 简化此过程的工具，上周我写了一篇关于它们的广泛博客文章。特别是，该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 的 rebase 建议，除了向后移植过程更加结构化，并且通过在后台使用 git 注释，您可以获得一些方便的额外功能，包括描述该过程的所有元数据在多次运行git cherry-menu.

当然，如果你只有少数提交到 backport，kan 是对的，你不妨直接挑选。

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

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

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

于 2013-09-23T11:52:10.393 回答