svn - 在项目中使用主干、分支和标签

Question

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

Answer 1

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

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

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

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

Answer 2

看看这两篇文章：

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

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

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

Answer 3

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

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

完成新功能后，应将分支合并回主干，然后可以删除分支。

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

Answer 4

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

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

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

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

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

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