在我工作的公司,我们使用 subversion 和 TortoiseSVN 来管理我们的源代码。每个项目都是从主干分支出来的。当我们需要为发布集成不同的项目时,我们会创建一个发布分支,其中包含将被集成、测试和部署到生产环境的代码。通常我们只有一个发布分支。
然而,最近,其中一个项目中的一些项目被推迟了,并计划进入下一个版本。结果,有人要求创建第二个发布分支来保存延迟的更改并防止它们合并到当前版本中。
到目前为止,这给我们带来了很多痛苦和很多树冲突,因为未来发布分支中的某些项目依赖于当前发布分支中的项目。我们能够解决这些问题的唯一方法是等到当前版本部署完毕,将发布分支合并到主干,将主干合并到未来发布分支,然后将项目分支的更改合并到未来发布分支.
由于这个问题,我们不得不建议我们永远不要拥有多个发布分支,因为它会导致合并问题。
但是,我想知道这是否是正确的方法。有谁知道是否可以在颠覆中管理多个发布分支?当然,必须能够在不影响合并能力的情况下管理延迟的特性。
有没有人有任何关于我提出的场景的经验,你愿意分享?我只是想知道如何改进在我的工作场所管理发布的方式,这样就不会再发生这种情况了。