SVN：主干、分支和标签答案

【问题标题】：SVN: trunk, branches and tagsSVN：主干、分支和标签
【发布时间】：2010-09-28 18:21:17
【问题描述】：

这是我试图找出解决问题的最佳方法的一个月，这是最好的。我想知道你是否同意。

我们正在开发一组相互关联的 Web 应用程序。我们将每个应用程序视为独立于其他应用程序的单一解决方案。每个应用程序由不同的项目组成，但这并不重要。

我们用于在主干上开发新功能。每当我们实时发布内容时，我们都会用版本名称标记主干版本。例如，假设第一个主干版本标记为 1.0.0。当我们开发进一步的实现（即我们正在开发 1.1.0）时，生产版本会出现一系列错误。我们正在考虑做的是检查标签 1.0.0 并更正版本 1.0.1 的错误。

现在我们想要完成的是标记每个修订版本。换句话说，我们希望能够拥有 1.0.0、1.0.1、1.0.2 ... 的完美工作副本......

现在这是我的解决方案，我想知道你是否同意。

对于每个新的错误/新版本等等。我试过了，如果我检查 /tags 文件夹，我可以看到所有版本，完美的工作。

现在，当我准备好 1.1.0 时，我应该使用“合并一系列修订”选项合并主干上的最后一个标签（或分支，如果一切正确，它们最后应该是相同的）。合并所有内容后，我应该有一个完整的 1.1.0 版本，并且过去已更正了修订。编译、测试然后发布，显然，将其标记到服务器上的 /tags/1.1.0 文件夹。

你怎么看？谢谢，马可

【问题讨论】：

曾经考虑过使用 DVCS？有了这么多的分支（和合并）和标记，它们可能比 SVN 有很大的优势
我不确定迁移到 DVCS 是否一定会改变这里的任何东西。分支/标签/主干结构在 SVN 中是标准的。迁移到不同的系统可能会迁移到不同的范例，但不一定是因为它是分布式系统还是集中式系统。
@Andrew：+1，我想知道“DVCS 解决所有问题”的想法是从哪里开始的，有些东西只是开发策略，与工具无关。
嗨 knittl，抱歉，我真的不知道 DVCS... 使用它们可以获得哪些优势？谢谢，马可

【解决方案1】：

通常所有的开发都是在主干上完成的，主干是你发布的基础。您可以使用分支来稳定代码以准备发布、修补发布或实现由于多种原因而无法在主干上开发的功能。

当使用分支进行稳定化或修补发布时，错误的修复或应该进入稳定化分支的更改都在主干上开发，并有选择地合并到分支。

当使用功能分支时，您提交到分支，然后合并回主干（可能从那里合并到稳定/补丁分支。

简而言之，我想念您开发周期中的主干，我想知道您如何确保所有更改最终都在主干中，因为这是您的下一个主要功能发布将/应该开始的地方。

【讨论】：

您好 Sander，感谢您对我的问题感兴趣。 Trunk 是我们开发新功能的地方，也是我们继续努力达到新的次要或主要版本的地方。如果我理解得很好，你是说如果我修复了分支上的错误，一旦我提交它，我应该立即合并所有内容。为什么最后不这样做？通过修复进行修复更安全吗？谢谢，马可
我的意思是，如果您的代码中有错误，那么它可能也是主干中的错误。因此，如果您首先在主干上修复它，您保证新版本包含对该错误的修复。之后，您可以在分支上为发布等准备补丁
我不同意在树干中修复并将cherrypick-合并“向上”到分支中。修复应该优先去稳定分支，并且可以“向下”合并到主干中，而不必担心为合并选择错误的更改。很可能定义一个通用的“在此处检查修复，将所有更改合并到主干”策略。

【解决方案2】：

这看起来是一个非常好的过程，除了你在生产分支上的错误修复很可能也需要反映在主干中。因此，最后不需要将所有内容合并到主干中，因为您已经完成了。

否则，您似乎确实正确地使用了分支和标签，所以对此表示赞赏。我见过太多无法在源代码控制中识别当前（或其他）生产版本的项目（如果您需要修复某些东西或回滚，这是必不可少的）。在我看来，这没有任何借口。

【讨论】：

您好安德鲁，感谢您的回复！为什么说不需要把所有东西都合并到trunk中呢？如果不通过合并，我将如何修复主干上的错误？谢谢！马可
@Marconline 你边走边合并，而不是最后。当您修复生产版本中的错误时，您很可能在主干中遇到相同的错误。因此，您当时会将生产分支中的错误合并到主干中。当您准备从主干发布时，您已经从主干的开发分支中修复了所有错误。因此，无需再合并到主干中。
我认为这就是 Sander 所说的......如果我合并 LAST 分支，我应该有相同的行为，我错了吗？您的解决方案可能更好，因为我可以在树干上开发几乎实时纠正错误...
@Marconline 作为最佳实践，您确实应该随时更新主干并修复错误。我注意到@Sander 提倡在主干中进行错误修复并将它们合并到相关的生产分支中。只要修复工作在两个地方完全相同，这也可以正常工作，但在实际情况下，我发现我需要先修复生产代码，然后确保修复工作在主干中。所以，我会在生产分支上实现我的修复，然后合并到主干。不过，这只是我的偏好。

【解决方案3】：

对我来说，您所描述的听起来像是标记和分支的正常程序。这就是我使用颠覆的方式，而且效果很好。

【讨论】：

【解决方案4】：

听起来不错。

根据发布的修复数量，我不会为每个小版本创建分支而烦恼。创建这些，与人们交流要签出的内容/签入的位置，合并等。冲洗并重复。

每个主要版本都有一个分支并将其用作“维护”分支，这对我们来说效果很好。

仅当您必须执行不符合当前策略的操作时，才为分支定义策略并创建新分支。有助于限制分支。

【讨论】：