何时使用颠覆创建新的分支/标签？答案

【问题标题】：When to create a new branch/tag with subversion?何时使用颠覆创建新的分支/标签？
【发布时间】：2015-03-21 03:49:41
【问题描述】：

我们正在使用 Subversion 开发一个 PHP 项目。到目前为止，我们一直在使用主干 (/trunk) 进行开发，最后我们发布了 1.0 版本（首先是 /branch/RB-1.0，接下来我们将其标记为 /tag/REL-1.0）。

我的想法是将错误修复发布为 1.0.x，并将新功能发布到 1.x，仅在我们有一些重要更改时才发布新的大版本（2.0，...）。

我不知道什么时候建议做一个新的分支/标签。仅适用于主要版本（1.0、2.0、...）、普通版本（1.1、1.2、2.1、...）或错误修复（1.0.x）？

当我要发布错误修复时，是否建议在主干或 RB-1.0 上修复它并将其合并到 TAG-1.0 而不创建新的分支/标签？标记/分支必须不必要地占用大量空间，不是吗？因此版本号 (1.0.x) 不会反映在 subversion 中，只会反映在我的变更日志中。

是否有关于何时分支/标记的“非官方”建议？

谢谢

【问题讨论】：

虽然可能有最佳实践（google for semver + svn 并忽略包管理器的所有结果），但这主要取决于您的团队来决定。它主要以标记其他人可能使用的所有内容和适当的分支结束。
你在这里有一些关于分支策略的好答案：stackoverflow.com/questions/34975/branching-strategies。阅读它们并找到最适合您情况的混合物。
我在这里找到了一个很好的解释我的疑问：What do "branch", "tag" and "trunk" mean in Subversion repositories?

标签： php svn version-control versioning

【解决方案1】：

你不应该合并到一个标签。制作一个新标签。标签在你制作之后应该是不可变的，否则它们就没有意义了。你应该会说“tag_1.0”并且确切地知道那是什么意思，并且在 3 年后应该是同样的意思。

不用担心空间问题。在服务器上，如果您在创建标签或分支时未进行任何修改，则不会为标签占用额外空间（存储名称和一些元数据所占用的空间除外）。在工作副本中，如果您检查整个存储库树——标签、分支和所有内容——只会占用额外的空间——无论如何你都不应该这样做。当您进行更改时，只有更改本身的空间（实际更改的两三行）才会占用空间。

关于合并方向：我认为 SVN 中的通常做法是修复主干，然后 backport 更改为您积极维护的所有分支。 SVN book chapter on branch patterns 讨论了这种方法。这在 SVN 中效果很好，因为 SVN 可以像完全分支合并一样轻松（甚至更容易）进行cherry-pick 合并，并且在合并方向上没有任何真正的优势。

其他项目，尤其是在使用其他版本控制系统时，则相反。例如，Mercurial 项目（使用 Mercurial）grafts bugfixes forward from release branches 而不是从其“默认”分支（相当于 SVN 中的主干）向后移植更改。显然 Mercurial 中的合并机制以这种方式工作得更好，但正如我所提到的，我认为 SVN 的任何一种方式都没有明显的优势。

分支策略完全取决于你，但我有点建议保留一个 1.0.x 分支和一堆 1.0.1、1.0.2 等标签。可能会再次分支 1.1.x、1.2.x 等。

您可以随时重新访问您的分支策略并根据需要重命名/删除分支。如果您需要再次查看它们，它们将始终在您的历史记录中可用。

【讨论】：