乌龟SVN将多个分支合并到主干中

我知道与乌龟SNV的合并已经讨论过了（很长时间），但我找不到我的情况的答案。我知道我可以使用合并向导将一个开发分支合并到主干中，但是如果我想将多个分支合并到主干中，正确的工作流是什么

在我的情况下，我从一个项目主干创建了三个开发分支（每个开发人员一个）。最初，dev分支和主干是相同的。开发人员也在项目的不同区域工作，因此多人不使用相同的文件。例如，我有trunk，b1，b2和b3，其中trunk=b1=b2=b3

现在，经过一些开发之后，我想将每个开发分支的更改合并回主干中。这就是我感到困惑的地方。我已经读到，您可以简单地将每个分支合并到主干中，一次一个（在合并下一个分支之前提交每个分支的更改），因为它们都有相同的故事，而且乌龟足够聪明，知道应该更改什么。因此：

b1 -> merge to trunk -> commit trunk (now trunk has b1 changes)
b2 -> merge to trunk -> commit trunk (now trunk has b1 and b2 changes)
b3 -> merge to trunk -> commit trunk (now trunk has b1, b2, and b3 changes)

我还读到，您应该将开发分支更改合并到其他开发分支中，然后合并到主干中，这样就不会出现覆盖问题（我认为tortoise足够聪明，可以避免）。因此：

请告知一种方法是否优于另一种方法，或者一种方法是否存在缺陷。我担心的是，如果我合并一个分支的更改，然后合并另一个分支的更改，我将撤消第一次合并操作中的更改，或者导致元数据出现问题

我使用的是陆龟vn版本1.8.8，构建25755和Subversion 1.8.10

---

谢谢

在将分支合并回主干之前，应将主干合并到分支中。在Subversion 1.8之前，在合并到主干时必须指定

--reintegrate

标志，但是Subversion通过新的功能来处理这个问题。以下工作流在SVN手册的第页中介绍：

将主干合并到b1

提交b1上的更改

将b1合并到主干

在主干上提交更改

删除b1

---

重复b2和b3的步骤。

谢谢您的建议。在将开发分支合并到主干之前，您能告诉我为什么要将主干合并到开发分支中吗？我以前读过关于这样做的文章，但不明白为什么在知道主干没有改变的情况下要这样做。这仅仅是一个好的实践吗？如果主干没有更改，则不需要将主干合并到分支中。在一般情况下，存在冲突的可能性，最佳做法是在合并到主干之前在分支上解决这些冲突。一旦您将主干的头部合并到分支中，解决了所有冲突并提交了更改，则在将分支重新整合到主干中时将不会发生冲突（在1.8中运行合并时，重新整合合并是隐式的）。请注意，在您重新整合b1后，主干将发生更改，这就是我描述一般工作流的原因。我将再次阅读。也许第二次会更有意义。另外，我想我刚刚回答了我自己的问题。在分支到主干合并之前，从主干到dev分支的合并是不正确的，因此正在合并的当前dev分支将从以前的合并中获得更改。基本上是执行我展示的第二个工作流，但通过主干本身并纠正冲突。对的再次感谢您的澄清。是的，没有详细说明为什么在您的案例中只合并到主干和从主干合并更好，这是正确的。无论您遵循哪个工作流，您都不必担心撤消更改。Subversion将标记合并冲突，您可以在提交更改之前查看更改。您始终可以还原工作复制上的任何操作，包括合并操作。只有在您提交更改时才会记录。这就是说，通过使用适当的工作流程，您完全可以避免合并困难。更多信息请参见我的答案。

b3 -> merge to b2 -> commit b2 (now b2 has b3 changes)
b2 -> merge to b1 -> commit b1 (now b1 and b2 and b3 changes)
b1 -> merge to trunk -> commit trunk (now trunk has b1, b2, and b3 changes)