我使用乌龟svn。但对于svn来说，我一般都很陌生。尽管我有一些git的经验。重新集成一个分支而不合并在树干变化
在实况它说
复兴分支
这个方法覆盖了你已经 一个特性分支在Subversion手册中讨论的情况。 所有中继线更改已逐个移植到功能 分支，现在该功能已完成 要将其合并回中继线。
据我理解这一点： 正常的工作流程，一个特性分支会，做出特色的分支，不就可以了发展，从主干分支错误修正在修订的范围内频繁地合并。功能完成后，进行树干更改的最终合并，然后将分支重新集成到树干中。
所以我有一些问题：
或多或少
频繁的合并从主干点到你的特性分支是它的零碎：小且易于管理。当冲突出现时，它们可以在你心中变化的情况下得到修复。如果您在重新集成之前没有将主干中的更改合并到功能分支，则不会发生任何“不良”情况。只需要处理合并所有更改一次，这可能会产生很多冲突，并且您甚至可能不记得导致冲突的代码部分，学习该代码并花更多时间解决冲突。如果您的干线和功能分支每天同步，则可能会每天多花5分钟时间来执行同步和清除冲突。如果您将其保留至功能分支的末尾，您可以花一整天或两天的时间解决所有冲突。
见Reintegrate a branch vs merge a range of revision，What are the differences between merging a range of revisions vs. reintegrate in SVN?和Consequences of not using --reintegrate with svn merge back to trunk
SVN用户更加比git的友好。它是集中式的，以TortoiseSVN的形式有很大的Windows GUI。最新版本的TortoiseSVN删除了“重新整合”选项，因为它可以在您这样做时自动计算出来。当您选中合并修订版时，它会将此信息存储在SVN中，因此下次您可以通过容易看到，看看哪些修订已被签入，等等。
首先简单介绍几乎所有版本控制系统的工作原理和工作原理。
标准合并是一种三种合并方式。在此，您将两个版本的最后一个共同祖先与两个版本进行比较。例如，我从树干分支。分支前的主干上的版本是最后一个共同祖先。
目的是为了能够看到一个流与其他流的变化。 （一个流可能是一个特定的分支或干线）。例如，如果我正在从树干合并到分支，我想确保不会用树干上的这些行覆盖我的特定分支更改。
与上一个共同祖先的比较可以让您仅查看自该分支点以来发生在树干上的变化。
当我从以前的合并中倒退时，会出现问题。例如，我完成了我的功能分支，并希望所有功能更改都在主干上。这是一个问题，因为我已将所有树干更改合并到分支上。这意味着我的分支的流显示我对分支进行了更改，并且这些应该合并到主干中。但是，这些变化已经在主干上了！要处理这个问题，你可以强制双向合并。在这种情况下，您只将两个独立流的头部相互比较，并将所有差异从一个流复制到另一个流。
现在怎么颠覆处理合并：
首先，颠覆爱挑樱桃mergin。 Subversion允许你指定你想要合并的版本。例如，我有一个分支，发现了一个bug并将它修复在分支上。我现在可以合并包含我的错误修复的特定修订版或修订版集。当你在Subversion中挑选樱桃时，你正在做一个三方合并，但你只考虑那些特定的樱桃挑选的版本中所表示的变化，而不是树干或分支上的所有变化。
事实上，即使您没有指定樱桃挑选修订，Subversion几乎总是会进行樱桃挑选合并。 Subversion追踪通过svn:mergeinfo属性合并的修订版本。假设我在版本100分支，现在我正在将我的主干更改合并到我的分支中。最新的trunk版本现在是版本150. Subversion认为你正在从版本100（但不包括版本100）到修订版本150的所有版本上进行樱桃选择。下一次我从我的trunk到我的分支（假设我的主干最后一次更改为175），Subversion将樱桃挑选从（但不包括150）到修订175的变化。
请注意，当我指定樱桃挑选版本，我可以毫无问题地在我的分行和我的行李箱之间来回走动。如果我从我的功能分支合并到我的主干，我可以在我实现该功能的功能分支上指定修订，并跳过作为从主干合并结果的功能分支上的更改。
这个问题，只有当我让Subversion处理樱桃采摘。当我从我的分支合并到我的分支时，Subversion跟踪我分支上的我的分支的修订。然而，Subversion无法知道我的特性分支上的哪些修订是我的主干合并的结果。因此，当我将我的特性分支合并回主干时，Subversion会考虑所有未合并的修订 - 包括那些由分支合并到分支的修订，并尝试将所有这些修订合并回我的主干。
为了处理这个问题，Subversion有一个特殊的合并，称为重新合并合并。我将我的最后一组变化合并到我的分支中，然后当我将分支合并到我的主干时，我希望我的主干和分支完全相同。因此，Subversion想要进行双向合并，并使树干和分支匹配。
在老版本的Subversion中，我将不得不手动指定我正在与svn merge命令中的--reintegration参数进行双向合并。
Subversion的合并跟踪还导致重复使用功能分支的一个有趣的问题。假设我做了从trunk到我的分支的最后一组合并。在trunk上的最后一次修订和Subversion的最后一次修订是修订版100.当我将我的更改从trunk中合并到我的分支上时，现在我在我的分支上创建了修订版101。该分支上的svn:mergeinfo属性表明，我已将我的所有更改合并到只有我的分支的主干上的修订版本100。
现在，我做我的重新整合合并，提交更改，并在我的主干创建修订版102。
现在，我在我的主干上做了更多的工作（比如修订版103），并且我想将这些更改合并到我的功能分支上。
从trunk到我的特性分支合并的最后一次修订是什么？看着svn:mergeinfo，我看到它的修订100.而且，由于从主干分支，去年的合并，现在有一些还没有被合并到我的特性分支树干上的两个新版本：版本102和103.修订
所以，Subversion会执行挑选樱桃并尝试将修订版本102和修订版本103中包含的更改合并到我的功能分支上。但是等等...修订版102是我的所有功能分支更改被合并到主干上！我将重新将这些功能更改应用于我的功能分支！
有两种方法可以解决这个问题：方法一：一旦你做了重新整合合并，你永远不应该再次使用该功能分支。删除它。把它锁在庵里。不要再说出它的名字。如果我再次需要该功能分支，我应该从主干创建一个新的功能分支。
的另一种方式是Munge时间svn:mergeinfo的特性分支进行颠覆知道中继线修订版102已经被合并到我的特性分支。你可以用--record-only参数做到这一点：
$ svn co $REPO/branches/feature/myproj
$ cd myproj
$ svn merge --record-only -r102 $REPO/trunk/myproj
正如你所看到的，这一切的手动工作 - 知道何时使用--reintegration开关和理解，当你做一个重返社会合并发生了什么 - 引起的混乱。因此，更新版本的Subversion（我相信自修订1.8版本）现在试图为你处理这个问题。
如果您使用Subversion 1.8作为客户端，则不必指定--reintegration参数。 Subversion将以编程方式确定您正在进行典型的三路合并还是合并，并进行相应的合并。
如果我试图做什么颠覆认为一个重返合并，而我还没有合并，所有我的树干修订到我的特性分支，Subversion会提醒我，不让我做的合并。如果我在重新集成合并时重新使用了一个功能分支，Subversion将会检测到这一点，并在重新集成后自动处理分支重用问题。 （有时简化版，相当的工作。但是，Subversion会不会让你重用安置在合并后的特性分支，但可能给你一个错误，你可能需要手动做--record-only合并。）
所以在Subversion中，你应该怎么做你的工作流程？
与Git不同的是，每个bug和特性都应该位于自己的分支上，所以您需要将该bug修复或特性合并到多个分支上，您几乎可以将所有工作都放在主干上（或任何您喜欢的分支）。在大多数Subversion商店中，分支仅适用于候选版本。也就是说，我即将发布一个版本，我为该版本分支。一些开发人员在发布上工作，其他人则继续在主干上工作。
如果在主干上发现了一个错误，它可以固定在主干上，并且该错误已修复的版本或修订版本可以合并到发布分支上。或者，如果在功能分支上发现需要在主干上修复的错误，则可以修复功能分支上的该错误，并将该修订或修订集合并到主干上。
它简单，直接，易于实现。
这并不意味着您不能分支功能。事实上，有时你必须这样做。想象一下正在深入实施的功能。您不希望在主干上进行这些更改。在这种情况下，请创建功能分支，并将您的主干更改定期合并到该功能分支上。请记住，将该功能合并到主干时可能会有问题。只要你明白发生了什么事情。没问题。
而且，如果你想疯狂地为每个功能和bug创建一个gazillion分支，你也可以这样做。不过，我建议你使用Subversion 1.8，它会为你做到这一点。
很多很好的信息 – Slav
Damm.You可以写一本svn书。 – Geddon