在项目中使用主干、分支和标签答案

【问题标题】：Use of trunks, branches and tags in a project在项目中使用主干、分支和标签
【发布时间】：2011-04-06 14:09:39
【问题描述】：

我知道理论，但是从项目的实际角度来看，如何使用 svn？比如说，我有一个网站，其中包含将要修改或添加的功能。在什么情况下会使用新的主干、分支和标签？

【问题讨论】：

看到这个答案stackoverflow.com/questions/5151760/…
树干就是其中之一。通常代表主开发线。为错误修复或某些替代开发线创建分支。标签就像里程碑，冻结的分支，代表开发时间线中一个没有错误、经过测试的发布点。

【解决方案1】：

不同的组织做的事情非常不同。 Alex 上面给出的解决方案是一个常见的解决方案，但是它遇到了一个问题，即只有在您登陆分支后，您才会发现其他分支与您的分支有冲突。这导致人们不得不调试他们已经有一段时间没有看过的东西中的冲突。

我遇到的另一种常见方法是在主干中进行所有开发，并让开发人员将所有提交设为小型、独立、提交。有多种方法可以添加功能并使其默认不可见，但在您的开发副本中打开。使用它们。这种方法需要开发人员的关注，但避免了管理寿命较长的分支之间的冲突带来的痛苦。

许多使用 Alex 的解决方案的人会跳来跳去说：“这对小团队之外的任何事情都不起作用！”对此我回应说，小团队没有任何问题，他们的生产力通常远远超过大团队所能做的任何事情。如果开发人员有纪律，这种策略可以扩展，例如谷歌使用它。如果您想查看使用该策略的实际项目，请查看http://llvm.org/。

还有一些建议。如果你想遵循 Alex 的策略，我强烈建议使用 git 而不是 svn。它比 svn 更好地处理分支。如果您想遵循我建议的策略，并且您的团队不是一个拥有您信任的人的小团队，您需要使用像 http://code.google.com/appengine/articles/rietveld.html 这样的代码审查工具来减少可能出现的明显问题。

【讨论】：

好点@btilly，我正在为我当前的项目尝试 Git - 到目前为止我非常喜欢它 - 但我不会在这里讨论主题:-)

【解决方案2】：

看看这两篇文章：

http://www.snuffybear.com/ucm_branch.htm

http://www.vance.com/steve/perforce/Branching_Strategies.html

来自SnuffyBear 的链接更多地说明了您似乎想要采用的策略，而other article 则讨论了其他策略，例如逐个发布分支。每篇文章都概述了每种策略的优缺点。

【讨论】：

【解决方案3】：

我会说一个单一的主干，其中进行了“稳定”的非常小的更改（可能是小错误修复），这不会破坏您的构建。

应为新功能/重大更改创建分支。在分支机构运营期间，分支机构应及时更新您的主干更改。

一旦你的新功能完成，分支应该合并回主干，然后可以删除分支。

标签用于发布。例如v1.2

【讨论】：

谢谢亚历克斯。很清楚的解释。重新表述，听起来在典型项目中很少使用额外的主干，而分支用于新功能。我已经假设标签用于发布。
只有当您只有一个版本在准备中时才会这样，否则您需要多个分支来代表正在准备中的特定版本（如 1.0、1.1 和 2.0）...
谢谢@James，顺便说一句。我必须补充一点，我自己很久没有使用 SVN。我的帖子更多的是结合了我在网上阅读的大量内容以及我自己正在尝试的内容。

【解决方案4】：

我的拙见：合并分支是可怕的。在许多情况下，不同开发人员所做的更改是完全独立的，因此可以顺利合并。但是在任何繁忙的项目中，都会有变更冲突的时候。如果幸运的话，SVN 会识别冲突并在合并时为您提供错误。如果你不那么幸运，SVN 不会捕捉到它，但它无法编译。无论哪种方式，现在都必须有人弄清楚如何将这些更改放在一起。有时这很明显也很容易。但是我有很多次不得不召集进行更改的开发人员，以便我们弄清楚该怎么做。

如果你很不走运，SVN 和编译器都没有发现问题，冲突的更改会进入生产环境，并且程序运行不正确。

从这个观察中我得出两个结论： (a) 尽可能少地创建分支。或者更准确地说，制定策略以尽可能少地进行合并。并且 (b) 在代码仍处于测试阶段时对代码进行合并。

有一段时间，我的公司有一个分支策略，即每个项目都有自己的分支，在该分支上进行测试，当我们准备好部署到生产环境时，我们合并所有分支以包含在该版本中，编译和部署。事实证明这是一个非常糟糕的主意。有人会在部署前一天尝试解决合并冲突，而合并的结果从未经过测试。许多微妙的错误悄悄进入生产环境。

我们暂时使用了这种策略：大多数开发都是在主干中完成的。当一个版本准备好移交给测试组时，我们会为它剥离一个分支。然后在主干中处理下一个版本。当前版本的任何错误修复都在分支中完成，并且此分支中的更改会定期合并回主干。有时需要同时进行 3 个版本的工作，即一个版本正在测试中，另一个版本接近准备好进行测试，现在我们需要开始下一个版本。在这种情况下，我们将拥有测试分支、当前版本的主干和下一个版本的“预”分支。当当前版本进入测试组时，我们会将“pre”分支合并到主干中，它成为当前版本。

我们最近开始尝试一种略有不同的策略。当一个版本处于测试阶段时，我们仍然会为它剥离一个单独的分支。但是任何来自测试的修复都是在主干中进行的，然后这些修复从主干合并到测试分支中。这意味着所有的开发都发生在主干中，而合并总是从主干到其他地方。这样做有两大好处：一是开发者总是在用trunk进行测试，所以我们对trunk中的代码是好的有更高的信心。测试组会针对发布分支进行测试，所以我们有信心发布分支是好的。也就是说，我们对这两个分支都将进行测试有一定的信心。当您在分支中进行更改然后合并回主干时。几乎无法保证有人会测试该合并的结果。二，trunk 总是有每个模块的完整“责备”历史。当您从分支合并回主干时。主干中的历史记录将分支的所有更改归因于进行合并的人，而不是真正进行更改的人，并且评论往往是无信息的“从分支 xyz 合并”。当您从主干合并到一个分支时，请确保该分支现在显示“错误”的人和一个无意义的评论，但主干具有良好的历史记录。有一个地方可以追寻历史，而不是试图追寻分支。

【讨论】：

你说：“如果你很不走运，SVN 和编译器都没有发现问题，冲突的更改会进入生产环境，并且程序的行为不正确。”据我所知，您没有单元和/或集成测试来验证合并的结果。我的声明：没有单元/集成测试比没有合并！任何版本控制工具都是如此。
您写道：“结果证明这是一个非常糟糕的主意。有人会在部署前一天尝试解决合并冲突，而合并的结果从未经过测试。”这就是所谓的“大爆炸整合”，它总是失败。特别是团队越大，合并就越复杂。简单的解决方案是尽可能多地将分支与主干（或稳定线路）同步。结果是只有可以简单处理的小合并。
有趣的东西，尤其是我没有意识到在合并后责备行为不正常。
@khmarbaise：这就是我的观点：我们在部署到生产之前进行了合并，没有测试合并的结果。有人得到了……有趣的……想法，如果单个更改经过测试并且有效，则合并的结果应该有效，因此无需“重新测试”。正如我在帖子中进一步所说的那样，这是一个非常糟糕的主意。