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

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

解决方案

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

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

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

我们可以继续在分支上进行开发，我们需要的功能是Subversion 1.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

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

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

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

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

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

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

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

$ 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章"分支和合并，高级合并"。