Question

当分支重新集成到主干时，该分支是否有效死亡？

重新整合后你可以对分支进行修改，并在以后将它们合并到主干中吗？

Answer 1

你可以在技术上做到这一点，你的分支既没有死也没有禁用，但是不建议在重新集成后从分支合并到主干。

您可以在此处找到有关其原因的完整讨论：Subversion merge reintegrate

基本上，它说，可以将您的更改再次合并到主干，但是由于重新集成会强制您在重新集成操作之前从主干到分支合并，您将面临反射/循环合并，这是非常有问题的在Subversion 1.5中根据该文章，建议在重新整合后立即删除重新整合的分支，并创建一个具有相同（或不同）名称的新分支。

这是一个已知的Subversion行为，将在未来版本中解决（可能在1.6中）

Answer 2

实际上，您需要从主干进行--record-only合并到由--reintegrate提交创建的修订的分支中：

$ cd trunk
$ svn merge --reintegrate ^my-branch 
$ svn commit

Committed revision 555. 
# This revision is ^^^^ important

现在你录制它

$ cd my-branch
$ svn merge --record-only -c 555 ^trunk 
$ svn commit

您很高兴现在继续分支

更多信息位于 Chapter 4. Branching and Merging, Advanced Merging 。

Answer 3

从分支机构重新集成到主干后，您应该执行以下两项操作之一：

Delete your branch。这是最简单的，但它更难以看到分支的历史。
Tell your branch not to merge the reintegrate commit。如果重新集成到主干，并将其作为修订版X提交，则可以在分支上运行此命令：svn merge --record-only -c X url-to-trunk。但是，如果您在提交过程中进行了任何更改，则不应执行此操作，而不是合并本身。任何其他更改都不会重新进入您的分支。

Answer 4

如果有人多次对分支进行更改（1.5之前的版本），请回复合并更改的一些建议：请记住您合并的修订版本！要么将修订号写在某处，或（这更容易）制作标记。（你当然可以在以后找到它，但那是PITA。）

示例：

您有这样的存储库布局：

/your_project
  /trunk
  /branches
  /tags

假设它是一个Web应用程序，您已计划发布。您将创建一个标记，并从该（或从主干）创建一个分支，您可以在其中执行错误修正：

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0

这样做，您可以将新功能集成到主干中。所有错误修正都只会在错误修复分支内发生，并且在每个版本之前都会生成当前版本的标记（现在来自错误修复分支）。

假设你做了大量的错误修正并将它们发布到生产服务器，你需要在当前主干中拼命地使用其中一个功能：

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2

现在，您只需将1.0.0和1.0.2之间的更改集成到主干中（假设您在工作副本中）：

svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .

这是你应该记住的。您已经在主干上合并了1.0.0和1.0.2之间的更改。我们假设当前的生产版本有更多变化：

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4

您现在已准备好从trunk发布新版本，但您的错误修正的最后更改仍然缺失：

svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .

现在您已经在主干上合并了所有更改，并且您可以进行发布（不要忘记先测试它）。

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
    /1.1.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4
    /1.1.0

Answer 5

不，分支仍然活着，但是，那一刻，它与树干完全相同。如果你继续在分支上进行开发，你可以在以后随意重新合并。

Answer 6

正如大家已经在这里说过的那样：分支机构还没有死，分支机构的承诺可以继续下去。

有时虽然你想在合并后杀死分支。唯一可靠的解决方案是删除分支。不利的一面是，如果你想看看它，那么再次找到分支是比较困难的，比如说，出于历史原因。因此，许多人离开了“重要”的分支机构并且同意不改变它们。我希望有一种方法可以标记死亡/只读的分支，从而确保没有人可以承诺它直到另行通知。

Answer 7

您可以根据需要多次从分支到主干，或主干到分支。

Answer 8

首先，如果仍使用Subversion 1.7或更早版本，则应升级Subversion客户端和服务器。没有理由使用非常旧的Subversion版本。截至2016年，当前版本为Subversion 1.9。 SVN 1.8现在也受支持，但仍然会收到错误修复。

你问的问题在Subversion 1.8中解决了。从SVN 1.8开始，--reintegrate选项已被弃用。现在，自动执行重新整合合并。请参阅Subversion 1.8 Release Notes entry related to the improvement。

阅读SVNBook 1.8 | Reintegrating a branch：

如果您选择在将分支重新集成到分支后不删除分支   trunk可以继续从trunk执行同步合并然后   再次重新整合分支。如果您这样做，只会进行更改   第一次重新整合后你的分支被合并到主干。

...

只有Subversion 1.8支持重用功能分支。前   版本需要在功能分支之前进行一些特殊处理   不止一次重新融合。请参阅本章的早期版本   欲获得更多信息：   http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Answer 9

进行合并时，指定目标。如果您愿意，可以将TreeA和TreeB的差异合并到TreeC中。正如克里斯所暗示的那样，你的问题并没有真正有意义。如果将分支合并到主干中，则分支保持不变。如果之后不需要分支，则可以将其删除。

Answer 10

您可以继续在分支上进行开发，您需要的功能是merge-tracking，它位于Subversion 1.5中，这意味着来自分支的其他合并仅包含新的更改。

Subversion分支重新整合

10 个答案: