颠覆分支重新整合

Question 1

当分支重新整合到主干中时，该分支是否有效地死了？

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

Question 2

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

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

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

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

Question 3

实际上，您需要--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

你很高兴现在保留分支

有关更多信息，请参见第4章“分支和合并，高级合并”。

Question 4

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

删除您的分支。这是最简单的方法，但是却很难查看分支的历史记录。
告诉您的分支不要合并重新整合的提交。如果您重新集成到主干并将其提交为修订版X，则可以在分支上运行以下命令：svn merge --record-only -c X url-to-trunk。但是，如果您在提交过程中进行了除合并本身以外的任何更改，则不应执行此操作。任何其他更改都永远不会使它回到您的分支中。

Question 5

如果有人多次对分支进行更改（1.5版之前），则有关合并更改的一些建议：请记住您在哪个修订版上进行了合并！可以将修订号写在某个地方，或者（更容易）制作一个标签。（您当然可以稍后找到它，但这是PITA。）

例：

您具有这样的存储库布局：

/your_project
  /trunk
  /branches
  /tags

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

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

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

假设您进行了大量的错误修复并将其发布到生产服务器，并且您在当前主干中迫切需要这些功能之一：

/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

现在您可以从主干发布新版本了，但是您的错误修正的最后更改仍然丢失：

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

Question 6

正如大家已经在这里所说的那样：分支并没有死，并且可以继续向分支提交。

有时，尽管您想在合并后杀死分支。唯一可靠的解决方案是删除分支。不利的一面是，如果您出于历史原因想查看它，那么很难再次找到该分支。因此，许多人离开了“重要的”分支，并同意不更改它们。我希望有一种方法可以将分支标记为已死/只读，从而确保在没有另行通知之前，任何人都不能提交它。

Question 7

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

Question 8

您可以根据需要从分支合并到主干，或将主干合并到分支。

Question 9

首先，如果仍使用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 | 重新整合分支：

如果您选择在将分支重新集成到主干后不删除分支，则可以继续从主干执行同步合并，然后再次重新集成分支。如果执行此操作，则只有在第一次重新集成后在分支上所做的更改才会合并到主干。

...

仅Subversion 1.8支持对功能分支的重用。早期版本需要进行一些特殊处理，然后才能多次集成功能分支。有关更多信息，请参见本章的早期版本：http : //svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

Question 10

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

Question 11

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