Svn 合并永久分支时是否需要重新整合？

这是我的布局

/trunk
/branches/qa
/branches/dev

我不打算在将来删除任何分支

从DEV合并到QA时，是否需要使用

--重新整合
？
或从QA到/中继

谢谢
如果合并方向始终相同（即您不从qa合并到开发人员，只从开发人员->开发人员），那么简单的合并就足够了

需要一种单独的模式（重返社会），以避免不必要的合并。在“功能分支”场景中，功能分支将有两种类型的更改：

定期提交
从主干合并
当我们想把功能放到主干中时，我们只想合并（1）。但是如果我们使用默认的合并机制，SVN也会尝试将（2）合并到主干中，这将导致冲突或隐藏错误，因为这些更改已经存在。
在两个分支（包括
主干
）之间使用重新合并，并打算保留源分支，通常是个坏主意。在以前的重新整合合并中，在将来的合并中，使用作为源的分支存在一些奇怪的问题

一般的解决方案是将源分支重新合并到
trunk
（应该是目标分支），然后从
trunk
合并后删除并重新创建源分支

然而，你想做一些稍微不同的事情

您是否应该在
dev
和
qa
之间进行重新整合合并？我的建议是避免重新整合合并，而是使用顺序合并或差异合并，合并时遵循创建路径（见下文）

通常，如果您希望将
dev
中的更改合并到
qa
，您可以将
dev
合并到
trunk
（并提交），然后将
trunk
合并到
qa
（并提交）。换句话说，你走的是创造之路。这在审核提交和合并时提供了一个漂亮、清晰的合并历史视图

如果这是不可能的，那么您需要格外小心地执行分支到分支的合并，这些合并通常只限于顺序合并。然后，当需要将
dev
或
qa
合并到
trunk
中时，这样做会容易得多

希望这有帮助。
分支之间的确切关系是什么？
qa
是
dev
的一个分支，而
dev
是
trunk
的一个分支，或者两者都是
trunk
的分支？
qa
和
dev
都是
trunk
的分支，我不同意这一点。考虑到分支的名称，相对安全的假设是
dev
和
qa
@SameerSingh之间会有双向合并：这取决于情况，单向合并的假设主要是猜测，但它基于问题中给出的两个合并示例