svn 分支和标记最佳实践答案

【问题标题】：svn branching and tagging best practicessvn 分支和标记最佳实践
【发布时间】：2010-07-29 01:43:41
【问题描述】：

我有一个项目，我准备为其创建一个分支，该分支将是 1.0.x 分支，用于所有 1.0.x 更改。我还希望有一组标签来对应对该分支的更改，即 1.0.1、1.0.2 等。当我第一次创建这个 1.0.x 分支时，我还创建了一个名为 1.0 的标签。此时，分支和标记具有相同的内容（因为我对 1.0.x 分支进行了更改，所以我将为 1.0.1、1.0.2 创建新标记，如上所述）。 svn 存储分支和标签的方式似乎有些重复。这是创建分支和标签的好习惯吗？或者有更好的方法吗？

谢谢，杰夫

【问题讨论】：

标签： svn branch tags

【解决方案1】：

svn 真的不关心项目是如何存储的，卡车、标签、分支布局只是一个建议。看起来您将使用您的分支进行主线开发，然后标记分支以部署为一个版本。对我来说，看起来你正在使用传统上在主干中完成的分支。这是一个非常标准的开发周期：

build new features -> stop new features, stable trunk -> tag version -> build new features in trunk (repeat)

然后，如果您需要修复标签中的任何错误，请确保将它们移植到主干。

这过于简单了，但这是一个很好的起点。

【讨论】：

请查看我对@Michael Shimmins 帖子的评论。我正在分支，因为我可能需要在各种版本上进行并行开发，即修复将成为 1.0.1 的 1.0，并且还分别继续开发 1.1 版本（并将更改从 1.0.x 分支合并到 1.1 )。

【解决方案2】：

svn 存储分支和标签的方式似乎有些重复

分支和标记在SVN中是一样的。

听起来您正在为主要版本分支中的每个次要版本分支分支。基本上是版本分支中的功能分支。

如果您在标签中进行更改，我会分支而不是标签以保持一致。如果您要标记分支以保留次要版本的标记点以供将来参考（例如：能够获取用于构建 1.2.7 的代码的快照），那么标记是正确的。

我通常标记主干（假设您将主干用作“稳定分支”）。我为版本/功能分支了主干，一旦完成并通过了 QA，我将这些分支合并回主干。然后我标记 trung 以将其标记为用于构建版本的代码。然后我删除功能分支，因为它已合并回主干。

分支分支没有错，它可以深入到你想要的深度，尽管合并可能会（从概念上）变得更难。

【讨论】：

感谢您的回答。要添加更多信息，我担心的一件事是如果将 1.0 版部署到我们的客户并且我们已经启动了 1.1 版会怎样。然后客户需要一个 1.0 的补丁，它变成了 1.0.1，但 1.1 中的功能还没有为客户准备好。现在我可以修改 1.0.x 分支并创建 1.0.1 而不给出 1.1 版本，这就是我考虑分支的原因，即使是小版本。但是我创建版本 1.0.1 时，标记它以供参考是否有意义（假设我的分支/标记方案有意义）？
是的 - 您可以将 1.0 标记分支为 1.0.1 分支，进行更改，重新提交并将其合并到稳定的主干中。然后，您将再次将稳定的主干标记为 1.0.1，其中仅包含 1.0 + 1.0.1 更改。 1.1 分支尚未合并到主干中，因此它仍然与发布隔离。您可以在将标签合并到其中后将主干合并到 1.1 分支，以便将您的 1.0.1 补丁更改合并到最新的 1.1 开发版本中。