•  01-07-2019
  •  | 
  •  

题

当一个分支是重返社会干线，是该分支有效地死了吗？

你可以修改的分支之后的重新融合及合并这些回到主干，在稍后的日期?

有帮助吗？

解决方案

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

您可以在此处找到有关其原因的完整讨论： Subversion合并重返

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

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

其他提示

实际上，您需要执行 - 仅记录从trunk到您的 - reintegrate commit创建的修订分支：

$ 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

您很高兴现在继续分支

更多信息请参阅 第4章分支和合并，高级合并 。

之后你重新融入社会的一个分支纳入主干，你应该做两件事之一：

  • 删除分支.这是最简单的，但它使得它很难看到该处的历史。

  • 告诉你的分支未来合并的重返社会的承诺.如果你重新融入社会的主干，并提交作为修订X，你可以上运行此命令你分支： svn merge --record-only -c X url-to-trunk.但是，你不应该这样做，如果你所做的任何变化的一部分犯下的，其他比的合并本身。任何其它变化，不会让它回到你的分支。

如果有人多次对分支进行更改（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

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

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

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

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

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

你问的问题在Subversion 1.8中解决了。从SVN 1.8开始， - reintegrate 选项已被弃用。现在，自动执行重新整合合并。请参阅与改进相关的Subversion 1.8发行说明条目。

阅读 SVNBook 1.8 |重新整合分支机构：

  

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

     

...

     

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

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

您可以继续在分支机构上进行开发，您需要的功能是合并跟踪在Subversion 1.5中，这意味着来自分支的其他合并仅包括新的更改。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top