在我工作的公司，我们使用 subversion 和 TortoiseSVN 来管理我们的源代码。每个项目都从主干分支出来。当我们需要为一个发布集成不同的项目时，我们创建一个发布分支，其中包含将被集成、测试和部署到生产的代码。通常我们只有一个发布分支。
然而，最近其中一个项目中的一些项目被推迟并计划进入下一个版本。结果，有人要求创建第二个发布分支来保存延迟的更改并防止它们合并到当前版本中。
到目前为止，这给我们带来了很多痛苦和很多树冲突，因为 future 发布分支中的某些项目依赖于当前发布分支中的项目。我们能够解决这些问题的唯一方法是等到当前版本部署后，将发布分支合并到主干，将主干合并到 future 发布分支，然后将项目分支的更改合并到 future 发布分支.
由于这个问题，我们不得不建议我们永远不应该有多个发布分支，因为它会导致合并问题。
但是，我想知道这是否是正确的方法。有谁知道是否可以在 subversion 中管理多个发布分支？当然，必须能够在不影响合并能力的情况下管理延迟的功能。
有没有人对我提出的你愿意分享的场景有任何经验？我只想知道如何改进我的工作场所管理发布的方式，以免再次发生这种情况。
最佳答案
老实说，根据描述，我并不完全确定您的系统是如何工作的。
但是，过去我不得不管理具有多个实时版本的项目。我们这样做的方式是:
通过这种方式，我们可以挑选哪些功能在哪个版本中。使用合并跟踪，它还可以让我们构建一个网页，以图形方式向我们展示什么去了哪里。
关键是拥有一个完全集成的分支，您可以从中挑选——这是我对主干的定义。
这不是一个完美的系统。如果您跳过版本，那么依赖关系会使事情变得棘手，我们确实需要图形化的东西来向我们展示什么是哪里，但总体上似乎运行良好。
另见我的回答 here .
关于svn - 如何在 subversion 中管理多个发布分支？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1163171/