如何从主干正确更新功能分支？答案

【问题标题】：How to properly update a feature branch from trunk?如何从主干正确更新功能分支？
【发布时间】：2011-01-09 22:13:00
【问题描述】：

The Subversion SVN book says:

...考虑这种模式的另一种方式是，每周同步主干到分支类似于在工作副本中运行 svn update，而最后的合并步骤类似于从工作副本运行 svn commit

我发现这种方法在大型开发中非常不实用，原因有几个，主要与重新集成步骤有关。

从 SVN v1.5 开始，合并是逐个修订的。挑选要合并的区域将导致我们两次解决主干-分支冲突（一次在将主干修订合并到 FB 时，一次在合并回来时）。
存储库大小：主干更改对于大型代码库可能很重要，从其他地方的主干复制差异文件（与 SVN 副本不同）可能会产生很大的开销。

相反，我们执行我们所谓的“重新分支”。在这种情况下，当需要进行大量主干更改时，会从当前主干打开一个新的功能分支，并且始终向下合并（功能分支 -> 主干 -> 稳定分支）。这不符合 SVN 书籍指南，开发人员认为这是额外的痛苦。

你如何处理这种情况？

【问题讨论】：

添加了 SVNBook 问题：code.google.com/p/svnbook/issues/detail?id=81
更新了我的答案...如果这没有帮助，那么我不明白这个问题。
SVN 1.5 再次更新

标签： svn

【解决方案1】：

从 SVN v1.5 开始，合并是逐个版本完成的。挑选要合并的区域会导致我们解决主干-分支冲突两次（将主干修订合并到 FB 时一次，合并回来时再一次）

那你做错了！

让我们看看：

trunk    fb
 ---------\
 r1-10    |
 r11-20   |
 r20-30   |

一般来说，如果你想在 11-20 完成更改，那么最佳做法是将 1-20 合并到 fb 把所有东西都拿到那里。

然后当fb完成后，合并20-30，然后复制 fb到trunk（不要合并！）。

如果您决定只合并 r11:20，好的，最后您需要合并 r1:10 和 r20:30 然后复制 fb到trunk。

您无法将更改合并两次！

我假设您可能会执行以下操作：

copy trunk->fb
merge 11:20 -> fb.
merge fb-1:30 -> trunk !!!!! WRONG

您不能这样做，因为您会合并两次 11:20。您应该始终将代码合并到只有一个方向。

正确方法：

copy trunk->fb
merge 1:20 -> fb.
merge 21:30 -> fb (now fb=trunk+feature)
copy fb -> trunk

编辑

所以正确的步骤是：

从主干创建功能分支（FB）（使用 svn-copy 将主干复制到功能分支）
```
FB_0=trunk_0
```
在 FB 上工作。
```
FB_1=FB_0 + change_a
```

将所有即将发生的更改从主干合并到 FB。

trunk_1=trunk_0 + tr_change_a;
FB_2 = FB_1 + (trunk_1 - trunk_0) == trunk_0 + change_a + tr_change_a

在脸书上工作
```
FB_3 = FB_2 + change_b
```

将所有即将发生的未合并的更改从主干合并到 FB。

trunk_2=trunk_1 + tr_change_n;
FB_4 = FB_3 + (trunk_2 - trunk_1) == trunk_0 + change_a + change_b + tr_change_a + tr_change_b

此时我们有一个功能分支，其中包含所有新功能和主干中的所有变化。所以我们只是复制两个分支之间的差异。
```
trunk_3 = trunk_2 + (FB_4 - trunk_2) = FB_4 = trunk_0 + change_a + change_b + tr_change_a + tr_change_b
```
现在 FB 被删除，因为 trunk 有我们需要的所有更改。

最后一步的执行者：
```
svn merge /path/to/trunk@LatestRev /path/to/branches/fb@LatestRev .
svn ci
```
或者用普通话来区分主干和分支并将它们放在主干使它们等效。

http://svnbook.red-bean.com/en/1.4/svn.branchmerge.commonuses.html#svn.branchmerge.commonuses.patterns.feature 中描述了这种模式

如果这对你不起作用，那么我不明白这个问题。

Edit2：对于 svn-1.5

在使用 svn-1.5 时，您可以更简单地合并：

当您在功能分支上工作时，您只需不时合并主干的更改：

$ svn merge /path/to/trunk
Solve conflicts
$ svn ci

它会将您的 FB 与主干中的所有更改对齐。在 FB 结束时，您运行此过程再次确保一切都是最新的。你去后备箱跑

$ svn merge --reintegrate /path/to/fb
$ svn ci

在最后一个中，如果你按照所示工作应该没有冲突。

【讨论】：

Artyom，你把 FB 复制到主干是什么意思？你怎么能复制不是新项目的东西？
@Pavel Radzivilovsky 请参阅svnbook.red-bean.com/en/1.4/…，尤其是“复制合并”模式。另外你使用什么SVN版本？ SVN-1.4 的优点之一是一切都是手动完成的，您必须了解它的含义。仔细阅读本节，甚至进行模拟运行以了解该方案的工作原理。当然，如果您将某些内容合并两次，您就做错了。
@artyom 我明白文字，我不知道你在说什么。你做错了什么是一件好事，但我告诉你我在做什么以及为什么（见问题）
@artyom 您提供的链接中没有提到这种“复制合并”模式。你能解释一下你的意思吗？
@Assaf Lavie，我不太确定我们说的是同一种语言。看来我没看懂你的问题。如果我建议的链接没有解释如何做，那么我可能不明白你想要什么以及到底是什么问题。

【解决方案2】：

研究后：

在 visionmap 进行了多次头脑风暴之后，包括 Artyom 在内的 F2F 讨论、打开 SVN 书柜等 - 看起来这是不可能的。功能分支完全不像工作副本。更新它的唯一可行方法是重新创建一个新分支，如上所述。

【讨论】：

【解决方案3】：

我们是一家小公司，所以我不知道我们的解决方案是否适用于您的情况。我们所做的是从主干到稳定分支的逐个修订。我们可以通过两种不同的方式来做到这一点： - 确实需要修复，我们在提交到主干后合并 - 危险的修复/更改。我们等了几天，直到更改在主干中得到证明，然后我们合并

通过这种持续的合并，我们避免了大量的冲突。

我的 2 美分。

【讨论】：

谢谢，这就是我们所做的（对于稳定的分支）。然而，整个问题是关于特性分支的。当我们年轻的时候我反对他们，但随着我们的成长，他们似乎不可避免。减少主干噪音似乎超过了断开开发的任何缺点。

【解决方案4】：

遗憾的是，提到的所有内容都可以被认为是 hack。从分支上的主干进行更新可能会在将其带回主干时导致非常严重的问题，并为所有冲突中最糟糕的情况——树冲突打开了可能性。这是因为目录不被视为一等公民。最好的方法是将 Mercurial 与 SVN 扩展作为您的标准 SVN 客户端。它允许您在获得 Mercurial 文件夹处理功能的同时继续使用 SVN。

然后在 wworkstation 方面，您可以使用多种方法，这些方法提供了一系列功能，以适应 SVN 单一的多种情况。您可以使用常规补丁、补丁队列、从本地主干副本更新，而不会影响共享主干和其他各种方法。

这种方法适用于 SVN 的所有缺点。由于类似的情况，我不得不改用这种方法。即使你不立即使用这种方法，你至少应该尽快尝试一下。

【讨论】：

【解决方案5】：

我想我必须在这里为@Artyom 拿起棍子。我也认为如果你必须这样做

解决主干-分支冲突两次

出了点问题。而且我认为@Artyoms 的论点/解决方案非常可靠。

我相信@Artyom 可以写得更清楚的一件小事是，最后你将fb“复制”到trunk，你不使用svn copy，而是使用svn merge（或svn merge --reintegrate） .这可能是您在 Common Branching Patterns 中找不到“复制合并”模式的原因。

到目前为止，我一直在努力理解你在做什么，我不确定还能说什么。

这是我听到的：

相反，我们做我们所说的 “重新分支”。在这种情况下，当一个重要的主干变化是需要，打开一个新的功能分支从当前的树干，...

现在你有一个新的分支（我们称之为 b2），它相当于主干，对吧？哪里是“需要大量的主干更改”？我假设在fb？

...合并是总是向下（功能分支 -> 树干 -> 稳定的树枝）。

但是当你刚刚从主干创建 b2 时，没有什么可以合并到主干中，不是吗？而且您也没有将更改从 b2 合并到 fb （因为这与将主干合并到 fb 相同......）。那么“重大变化”是如何进入 fb 的呢？一旦它们在那里，为什么要将它们合并回主干（因为这是它们最初来自的地方）？

实际上，Common Branching Patterns 下的 SVN 1.4 文档中提供的以下链接 the section called “Tracking Merges Manually" 和/或 the section called “Merging a Whole Branch to Another"（我知道，您不使用 SVN 1.4 但我相信它仍然适用）可能有助于清除一些问题.这些链接在 1.5 文档中“缺失”（可能是因为 merge 中的新 --reintegrate 选项）。

您确实似乎将相同的更改合并了两次，我真的认为您不应该（需要）这样做。

【讨论】：

在创建 b2 之后，他正在合并从 fb 到 b2 的所有更改并丢弃 fb，继续在 b2 上工作。只要您希望与主干保持一致，就可以重复该过程，然后最终合并到主干。