在我工作的公司，我们使用 subversion 和 TortoiseSVN 来管理我们的源代码。每个项目都是从主干分支出来的。当我们需要为发布集成不同的项目时，我们会创建一个发布分支，其中包含将被集成、测试和部署到生产环境的代码。通常我们只有一个发布分支。
然而，最近，其中一个项目中的一些项目被推迟了，并计划进入下一个版本。结果，有人要求创建第二个发布分支来保存延迟的更改并防止它们合并到当前版本中。
到目前为止，这给我们带来了很多痛苦和很多树冲突，因为未来发布分支中的某些项目依赖于当前发布分支中的项目。我们能够解决这些问题的唯一方法是等到当前版本部署完毕，将发布分支合并到主干，将主干合并到未来发布分支，然后将项目分支的更改合并到未来发布分支.
由于这个问题，我们不得不建议我们永远不要拥有多个发布分支，因为它会导致合并问题。
但是，我想知道这是否是正确的方法。有谁知道是否可以在颠覆中管理多个发布分支？当然，必须能够在不影响合并能力的情况下管理延迟的特性。
有没有人有任何关于我提出的场景的经验，你愿意分享？我只是想知道如何改进在我的工作场所管理发布的方式，这样就不会再发生这种情况了。
老实说，我不完全确定您的系统在描述中是如何工作的。但是，过去我不得不管理具有多个实时版本的项目。我们这样做的方式是：
这样我们就可以挑选出哪些功能在哪个版本中。使用合并跟踪，它还可以让我们构建一个网页，以图形方式向我们展示去了哪里。
关键是拥有一个可以从中挑选的完全集成的分支——这是我对主干的定义。
这不是一个完美的系统。如果您跳过版本，那么依赖项会使事情变得棘手，我们确实需要图形化的东西来向我们展示什么在哪里，但总体上看起来运行良好。
另请参阅我的答案here。
这不是乌龟擅长的地方。要执行复杂的合并和分支场景，您需要 clearcase config spec 之类的东西来进行版本控制。
如果你使用乌龟，你最好保持主干，然后在主干上运行持续集成，或者为每个特性创建分支，当特性开发完成时将它们合并回来。如果您这样做，那么您将只有经过测试的主干上的代码。然后您选择一个发布点，进行集成并将所需的修复带回您的主干，同时还允许您的团队继续他们的开发。
我认为您希望通过 svnmerge.py 或通过 Subversion 1.5 的内置合并跟踪进行合并跟踪。这允许您阻止某些更改被合并到一个分支中，然后可以对与您只想合并到下一个版本中的功能相关的所有更改执行此操作。
您几乎总是希望第一个延迟分支上的更改出现在第二个。所以第二个发布分支应该从第一个发布分支创建，并且应该定期合并第一个发布分支。理想情况下，由最初制作它们的人制作。
Spepladder(?) 分支在这种情况下会很好地工作——只需放弃树干并爬上去。
我的公司也有类似的问题。
我们有一个项目延迟了一个版本——我们称之为 2.0——几个月。与此同时，我们在当前分支上遇到了生产问题——我们称之为 1.5——需要发布更多版本。我们不能使用主干，因为它具有禁运功能，所以我们开始从分支分支。我们的 1.6 版本是从 1.5 分支出来的，而不是主干。除了命名约定之外，1.6 版本实际上只不过是 1.5.1。由于这不是 SOP，我们一直非常小心地记录我们正在做的事情。
而且我不期待合并点，我们最终将 1.6 分支和 2.0 结合在一起。我们无法将 1.6 上的更改合并回主干或 2.0，因为这只会让 2.0 问题的 QA 变得更糟。我们正在运行 Subversion 1.4.6，所以软件没有帮助 - 它将全部手动合并。