颠覆 - 任何人都应该开发干线吗？

Question

当使用Subversion时，开发人员是否应该在主干上工作，或者主干应仅用于来自每个开发人员分支的合并并由持续集成服务观看？

Answer 1

有两个基本策略：

• unstable trunk - 主干始终包含最新代码，分支用于发布
• 稳定的主干 - 代码是在分支机构中开发的，只有在经过全面测试并且从主干进行释放后才能检入主干

您使用的在某种程度上是个人偏好的问题。 但除此之外，个别开发者应该使用 为自己的实验发展分支。

像往常一样，没有明确的答案！

Answer 2

取决于更改的范围。一般的好习惯是主干应该始终是可编译的，但这并不一定意味着开发人员不能在主干上进行小的更改/错误修正 - 毕竟，这是拥有工作副本的原因之一;你可以确保在提交之前编译。

更大的更改或功能添加几乎总是被拉到分支中，直到它们准备好进行集成，以免干扰其他开发。

Answer 3

有许多方法可以使用版本控制系统进行并行开发。你在上面建议的那个没有错 - 但每个都有优点和缺点。我曾在两个方面工作过。

开发主干和剪切发布分支很好，但如果您需要执行紧急生产版本，则最终必须修补发布分支并再次释放 - 意味着在CI系统中构建分支。

在分支机构中工作并保留主干线（使用持续集成系统进行监控）也没问题，但可能会导致多个分支机构的开发人员发生冲突问题。

另请查看以下网站：

http://www.cmcrossroads.com/bradapp/acme/branching/

讨论了并行开发的一些分支模式，包括：

• S1。主线
• S2。并行维护/开发
• S3。重叠版本
• S4。对接线
• S5。分阶段整合线
• S6。更改传播队列
• S7。第三方代码行
• S8。内/外线

Answer 4

我认为这实际上取决于您的操作规模。最多可能有5-10名开发人员进入后备箱应该没问题。但是当然每个人都应该记住，主干需要始终是可编译的。如果他们正在进行一段时间无法编译的重大变更，那么他们应该转移到分支机构。

Answer 5

使用Subversion时，每个人都可以在中继之外工作。如果某个特定开发人员正在处理大型或“实验性”功能，那么为该工作创建一个单独的分支是明智的，可以稍后将其合并回主干。

虽然，您描述的方法，每个开发人员都有自己的分支，但是比Subversion更接近Git。如果这是您喜欢的工作方式，我强烈建议您使用Git。

使用Git，没有必要使用某种连续集成服务器来观察单独的分支。相反，每个开发人员都有自己的分支，只要他们愿意，他们就可以将它们合并回主分支。

Answer 6

我几乎总是在干线上开发的团队工作 - 工作正常。我并不是说这是最好的主意或任何事情，只是不值得反对，如果它会让你被解雇。

但是，我们的系统始终可以构建，并且通常也使用CI。每个开发人员都必须知道更新/重建/重新测试/提交周期（不是说它是万无一失的，但它运行良好）。

Hmph，当我想到我们有多少软件实践工作“足够”时会很痛苦。

Answer 7

我们的主干只是合并并修复紧急错误。当我们有一个新项目时，我们分支主干，在分支上开发，如果任何其他分支合并到主干中，则从主干重新绑定，当我们准备好测试时，我们部署分支。 当测试没问题时，我们合并到trunk，并发布到beta。 在合并之前，我们在主干上做一个版本以避免问题。

在测试结果正常后，我们会发布产品。

Answer 8

作为Neil Butterworth said，取决于;存在几种有效的方法。

但是，我个人建议拥有一个稳定的主干，并在临时分支上进行所有重大开发。 （即，只有一次完全完成的小型独立更改应直接转到trunk。）为了避免长寿命分支离主线太远，（auto）合并所有内容至少每天进入所有开发部门的主干。哦，所有应该由CI监视 - 不仅仅是主干，而且所有开发分支也是如此。特别是对哈德森而言，它很容易引起开销。

如果对我们如何应用此功能感兴趣，请在this answer中提供更多详细信息。 （我讨厌过多地重复自己......）

我实际上推荐这种方法，即使它只是一个团队在代码库上工作，而甚至如果每个人都在处理相同的功能/更改。为什么？好吧，因为根据我的经验（除非事情 - 例如发布时间表，要求等 - 在你的环境中是非常可预测的），所以你的主干始终处于可释放状态一定是值得的。

Answer 9

我正在使用我们产品的3.0版本，并将我的代码更改检入主干。发布还有几周时间。

同事正在尝试一些可能使其成为4.0的功能，但绝对不会进入3.0。她正在检查她的东西进入一个单独的分支。检查这种东西进入后备箱是不对的。

另一位同事正在修复2.5版本中的错误，我们已将其发送给客户。由于显而易见的原因，他正在检查他们进入2.5分支。

所以，回答标题问题（每个人都应该从主干开发，我的答案是否定的.HPH

P.S。关于合并。我们可以选择性地将一些东西从2.5分支合并到后台干线，但不能从干线回到分支。 trunk和4.0分支之间的合并可以双向进行。

Answer 10

有一个论点要求开发人员应该被要求在trunk上工作。

如果让它们分支，有些人会试图无限期地保持这些分支，并定期与主干交叉同步。这将不可避免地导致复杂的合并操作，而这些操作又会产生错误。

通过强制每个人进入主干，他们必须保持非常靠近头部，因此错误合并引入错误的风险会降低。此外，由于每个人都运行最新的代码，他们更容易发现错误，因为它们会逐渐增加，并且修复程序会更快地提交。

当然，有时候一个大的特征需要单独上演，但在这些情况下，可以进行特别批准的例外。

Answer 11

我有开发人员创建项目分支或从主干更改请求/错误分支，然后合并回来，所以在某种程度上是的，我让开发人员在主干上工作，但进入“合并”分支的是通过一些构建控制工具或过程。

我认为this question

很好地涵盖了这一点

Answer 12

是的，那应该是你发布的工作副本。您的所有分支都应该是代码的先前发行版本。

Answer 13

完全取决于您的发布时间表。如果当前正在定期检查的所有工作都要立即发布，则可以将它们全部检入一个区域，如主干。如果有一些工作会被阻止，而其他尚未完成的工作必须首先出去，第一个出去的代码可以提交给trunk，而下一个代码也可以提交给自己的分支，反之亦然。

你会发现合并和刷新的分支可能是偶然出错的麻烦。因此，自然而然地尽量减少这一点是有意义的源控制的总体思路是每个人都可以在一个地方工作。

通常当您获得更大的团队时，发布计划由子团队及其项目组织，并且这些团队有自己的分支。

Answer 14

是。
将您的最新分支机构作为最新版本是没有任何意义的。然后，你的行李箱已经过时了。

Answer 15

我认为如果你敏捷并在几周内以小增量发布，你应该在trunk中开发。通过这种方式，你拥有最新的trunk，它可以不断构建，可能会被破坏，但很快就会被修复，当你准备好发布时，标记并释放它。这样，也没有从分支合并的头痛。

我想我还要补充一点，如果你在分支机构中开发，你就不会敏捷。分支机构的开发仅适用于瀑布。

Answer 16

我认为您使用的工具也是一个重要因素。

• 如果您使用的是Subversion，不稳定的主干可能会更适合您。
• 如果您使用的是GIT，稳定的主干将比Subversion容易得多。

Answer 17

在我的公司，我们采用了稳定的主干开发模型，在合并到主干之前，正在开发代码并在分支上进行全面测试。 但我发现这种做法非常令人生畏，因为验证团队通常需要数月才能完全测试功能分支。所以我们最终将这些分支缠绕了好几个月才能将它们合并回主干。

另一方面是使用不稳定的主干开发，所有更改都会一直进入主干，但随后我们的验证团队开始抱怨他们对代码没有信心，因为每个人的变化总是在那里而且没有孤立。

因此看起来这些方法中的任何一种都不是最佳的。对于一个验证可能需要很长时间的团队，是否有更优化的方法？