您是继续在分支机构还是在后备箱中进行开发？

Question

假设您正在开发定期发布的软件产品。在分支和合并方面有哪些最佳实践？将定期发布分支机构切换到公众（或任何客户），然后继续在主干上进行开发，或者考虑使用稳定版本的主干，定期将其标记为发布，并在分支机构中进行实验性工作。人们认为树干被认为是“黄金”还是被认为是“沙箱”？

Answer 1

我已尝试使用大型商业应用程序的两种方法。

哪种方法更好的答案在很大程度上取决于您的具体情况，但我会写出我迄今为止的总体经验。

总体上更好的方法（根据我的经验）：主干应该始终稳定。

以下是此方法的一些指导原则和优点：

• 在自己的分支中对每个任务（或相关的任务集）进行编码，然后您就可以灵活地合并这些任务并执行发布。
• QA应该在每个分支合并到主干之前完成。
• 通过在每个分支上进行质量检查，您将确切地知道导致错误的原因。
• 此解决方案可扩展到任意数量的开发人员。
• 此方法有效，因为分支在SVN中几乎是即时操作。
• 标记您执行的每个版本。
• 您可以开发一段时间不打算发布的功能，并确定何时合并它们。
• 对于您所做的所有工作，您可以享受提交代码的好处。如果你只在干线上工作，你可能会保持你的代码不被提交很多，因此没有保护，没有自动历史记录。

如果您尝试相反并在主干中进行所有开发，您将遇到以下问题：

• 每日构建的常量构建问题
• 当开发人员为项目中的所有其他人提出问题时的生产力损失
• 更长的发布周期，因为您需要最终获得稳定的版本
• 不太稳定的版本

如果您尝试保持分支稳定并将主干作为开发沙箱，那么您将无法获得所需的灵活性。原因是你不能从主干中挑选你想要放在那个稳定版本中的东西。它已经全部混合在一起了。

特别是我要说在主干中进行所有开发的一个案例就是当你开始一个新项目时。根据您的情况，可能还有其他情况。

---

顺便说一下，分布式版本控制系统提供了更大的灵活性，我强烈建议切换到hg或git。

Answer 2

我已经使用过这两种技术，我会说在后备箱上进行开发并在稳定点上分支，因为发布是最好的方法。

那些反对说你会拥有的人：

  

  
• 每日构建的常量构建问题
  
• 开发人员为所有人提出问题时的生产力损失   该项目的其他人员
  

可能没有使用持续集成技术。

的确，如果你不在白天进行多次测试，比如说每小时左右一次，那么就会对这些问题开放，这些问题会迅速扼杀发展的步伐。

在白天进行多次测试构建会快速折叠主代码库的更新，以便其他人可以使用它，并在白天提醒您，如果有人打破了构建，以便他们可以在回家之前修复它。

正如所指出的那样，只有在运行回归测试的每晚构建失败时才发现破坏的构建是完全愚蠢的，并且会很快减慢速度。

在Continuous Integration上阅读Martin Fowler的论文。我们在大约2,000行Posix sh中为一个主要项目（3,000kSLOC）推出了我们自己的系统。

Answer 3

我倾向于采用“发布分支”的方法。行李箱很不稳定。一旦发布时间临近，我会发布一个发布分支，我会更谨慎地对待它。当它最终完成时，我会标记/标记存储库的状态，以便我知道“官方”发布的版本。

我知道还有其他方法可以做到 - 这就是我过去做过的方式。

Answer 4

两个

主干用于大部分开发。但预计将尽最大努力确保对行李箱的任何登记都不会破坏它。 （由自动构建和测试系统部分验证）

版本保存在他们自己的目录中，只对它们进行了错误修复（然后合并到主干）。

任何将使主干处于不稳定或非工作状态的新功能都在其自己的独立分支中完成，然后在完成时合并到主干中。

Answer 5

我喜欢并使用Henrik Kniberg在Version Control for Multiple Agile Teams中描述的方法。 Henrik在解释如何在多个团队的敏捷环境中处理版本控制（在传统环境中也适用于单个团队）方面做得非常出色，并且没有必要解释他所以我只是发布下面的“备忘单”（自我解释）：

我喜欢它，因为：

• 很简单：你可以从图片中得到它。
• 没有太多的合并和冲突麻烦，它可以很好地工作（并且可以扩展）。
• 您可以随时发布“工作软件”（本着敏捷的精神）。

以防万一不够明确：开发在“work branch（es）”中完成，trunk用于DONE（可释放）代码。查看Version Control for Multiple Agile Teams了解所有详细信息。

Answer 6

一个关于开发过程的一个很好的参考，它可以保持主干稳定并且所有分支都在分支中，是Divmod的Ultimate Quality Development System。快速摘要：

• 所有完成的工作必须有与之相关的故障单
• 为每张完成该故障单工作的故障单创建一个新分支
• 来自该分支的更改不会合并回主线主干，而不会被其他项目成员审核

他们使用SVN，但这可以通过任何分布式版本控制系统轻松完成。

Answer 7

我认为你的第二种方法（例如，标记发布和在分支中做实验性的东西，考虑到主干稳定）是最好的方法。

应该很清楚，分支会在分支的时间点继承系统的所有错误：如果修复程序应用于主干，如果您将分支维护为分支，则必须逐个进入所有分支。一种发布周期终结器。如果您已经发布了20个版本并且发现了一个早于第一个版本的错误，那么您将不得不重新应用修复20次。

分支应该是真正的沙箱，虽然主干也必须扮演这个角色：标签将指示代码在那个时间点是否为“黄金”，适合发布。

Answer 8

我们在行李箱上开发，除非变化太大，不稳定，或者我们正在接近我们其中一个产品的主要版本，在这种情况下，我们会创建一个临时分支。我们还为每个产品发布创建一个永久分支。我发现微软在Branching Guidance上的文档非常有帮助。 Eric Sink的tutorial on branching也很有趣，并指出对微软有用的东西可能对我们其他人来说太沉重了。在我们的例子中，我们实际上使用了Eric所说的团队所做的方法。

Answer 9

这取决于你的情况。我们使用Perforce并且通常有几行开发。主干被认为是“黄金”，所有开发都发生在分支上，当它们足够稳定以便整合时，它们会合并回主线。这样就可以拒绝不能进行切割的功能，并且可以随着时间的推移提供独立项目/功能可以提供的可靠增量功能。

融合和追赶到主干中的新功能会有整合成本，但无论如何你都会遭受这种痛苦。让每个人在后备箱上一起发展可以导致狂野的西部情况，而分支允许你扩展和选择你想要服用苦味集成药丸的点。我们目前已在十几个项目中扩展到超过一百个开发人员，每个项目都使用相同的核心组件进行多个发布，并且运行良好。

这样做的好处在于你可以递归地执行此操作：一个大的功能分支可以是它自己的主干，如果它有其他分支。此外，最终版本将获得一个新的分支，为您提供稳定维护的地方。

Answer 10

这取决于您的开发工作的规模。并行工作的多个团队将无法在相同的代码（主干）上有效地工作。如果你只有一小群人在工作，你主要关注的是削减一个分支，这样你就可以继续工作，同时回到分支机构，对现有的生产代码进行错误修复。这是一个微不足道的分支使用，而不是太繁琐。

如果你有很多并行开发，你会希望为每项工作都有分支，但这也需要更多的规则：确保你的分支经过测试并准备合并回来。调度合并，因此两个组不会同时尝试合并等。

有些分支机构正在开发中很长时间以至于你必须允许从主干到分支的合并，以便在最终合并回主干时减少意外数量。

如果你有一大群开发人员，你将需要进行实验，并了解你的情况。以下是Microsoft提供的页面，可能有点用处：http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx

Answer 11

我们正在使用主干进行主要开发和分支发布维护工作。它很好用。但是分支应该仅用于修复错误，没有重大更改，特别是在数据库方面，我们有一条规则，即只有架构更改才能在主干线上发生，而且永远不会在分支中发生。

Answer 12

尝试根据新开发来管理当前生产代码的维护是最有问题的。为了缓解这些问题，一旦完成测试工作并且代码已准备好交付，代码应该分支到维护行。此外，主线应该分支以协助发布稳定，包含实验性开发工作，或支持其生命周期跨越多个版本的任何开发工作。

只有在代码之间存在任何其他方式难以管理的冲突的可能性（或确定性）时，才应创建非维护分支。如果分支机构没有解决后勤问题，它将创建一个。

正常版本开发发生在主线上。开发人员检查和退出主线以进行正常的发布工作。当前生产代码的补丁的开发工作应该在该版本的分支中，然后在补丁通过测试并部署后与主线合并。应根据具体情况协调非维护部门的工作。

Answer 13

如果你要完成一个发布周期，一个很大的功能，你就会被淹没到一个分支机构。否则我们在trunk中工作，并在我们构建的那一刻为每个生产版本分支。

之前的生产版本在那时被移动到old_production_，而当前的prod版本始终只是生产。我们所有的构建服务器都知道生产是如何部署生产分支的，我们用强制触发器来解决这个问题。

Answer 14

我们遵循trunk =当前开发流，branch = release（s）方法。在向客户发布时，我们将树干分支并保持后备箱向前滚动。您需要决定准备支持多少个版本。您支持的越多，您将在修复错误时进行更多合并。我们努力让客户在主干后面不超过2个版本。 （例如，Dev = 1.3，支持版本1.2和1.1）。

Answer 15

行李箱一般是主要的开发线。

版本已经分支，通常在分支上完成实验或主要工作，然后在准备好与主开发线集成时合并回主干。

Answer 16

对我来说，这取决于我正在使用的软件。

在CVS下，我只会在“trunk”中工作而从不标记/分支，因为这样做真的很痛苦。

在SVN中，我会在主干中执行我的“前沿”工作，但是当需要对服务器进行适当的标记时，

我最近切换到git。现在我发现我从不在行李箱里工作。相反，我使用一个名为“new-featurename”的沙箱分支，然后合并到一个固定的“当前生产”分支中。现在我考虑一下，我真的应该在合并回“当前生产”之前制作“release-VERSIONNUMBER”分支，这样我就可以回到较旧的稳定版本......

Answer 17

这实际上取决于您的组织/团队管理版本的程度以及您使用的SCM。

• 如果下一个版本（在下一个版本中）可以轻松规划，那么你最好在后备箱中进行开发。管理分支机构需要更多时间和资源。但如果下一个不能轻易计划（在大型组织中一直发生），你最终可能会选择提交（数百/数千）而不是分支（几个或几十个）。
• 使用Git或Mercurial，管理分支比cvs和subversion更容易。我会去找稳定的trunk / topic分支方法。这就是git.git团队使用的内容。读：http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
• 使用Subversion，我首先应用了开发中的方法逻辑。在发布日期时有相当多的工作，因为每次我必须樱桃选择提交（我的公司不擅长计划）。现在我是Subversion的专家，并且非常了解Subversion中的manaing分支，所以我正朝着稳定的trunk / topic branches方法逻辑迈进。它比以前好多了。现在我正在尝试git.git团队的工作方式，尽管我们可能会坚持使用Subversion。

Answer 18

主干通常应该是您的主要开发来源。否则，您将花费大量时间合并新功能。我已经看到它以另一种方式完成，它通常导致很多最后一刻的集成问题。

我们标记我们的版本，以便我们能够快速响应生产紧急情况，而无需分配积极的开发。

Answer 19

以下是我更喜欢的SVN设计：

• 根
  • 发展
    • 分支
      • 特征1
      • 特征2
      • ...
    • 躯干
  • 测试
    • 标记
    • 躯干
  • 释放
    • 标记
    • 躯干

除了需要自己的分支的主要功能外，所有工作都是从开发/主干完成的。在针对开发/主干测试工作后，我们将测试的问题合并到beta / trunk中。如有必要，将针对测试版服务器测试代码。当我们准备推出一些更改时，我们只需将适当的修订合并到release / trunk和deploy。

可以在beta分支或发布分支中创建标记，以便我们可以跟踪beta和发布的特定版本。

这种设计具有很大的灵活性。它还使我们可以轻松地在beta / trunk中保留修订版，同时将其他版本合并到release / trunk，如果某些修订版没有通过测试版的测试。

Answer 20

我们使用的方法是Perforce方法，在Laura Wingerd的伟大着作中对此进行了详细讨论：

http://oreilly.com/catalog/9780596101855/index.html

虽然本书以perforce为中心（Wingerd是Perforce产品经理），但这些概念可以应用于任何或所有VCS。

perforce方法（和平台）为我们提供了很好的服务。它被许多公司使用（谷歌，Intuit，我听说过，微软Windows本身）。

这本书值得一读。

Answer 21

阅读本文：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf

Answer 22

对于颠覆惯例问题恕我直言，没有一个通用的答案。

这实际上取决于项目的动态和使用它的公司。在一个非常快节奏的环境中，当发布可能每隔几天发生一次，如果你试图进行宗教标记和分支，你最终会得到一个无法管理的存储库。在这样的环境中，根据需要采用分支方法可以创建更加可维护的环境。

另外 - 根据我的经验，从纯粹的管理角度来看，在您选择时切换svn方法非常容易。

我所知道的最好的两种方法是分支 - 何时需要，以及分支 - 每项任务。当然，这些是彼此完全相反的。就像我说的 - 这都是关于项目动态的。

Answer 23

@Brian R. Bondy：请注意，一旦您的团队达到项目并行处理的一定数量的人员/任务，这不是解决方案。

一旦质量保证部门参与qa，每个分支机构提供一个安装所需的工作就太高了。想想 SOA /客户端/服务器/ Web服务/数据库所有这些都必须提供每个分支。

这个解决方案缺乏整合阶段。