version-control - 您是在分支还是主干中继续开发？

Question

假设您正在开发一个定期发布的软件产品。关于分支和合并的最佳实践是什么？将定期发布分支划分给公众(或您的客户是谁)，然后在主干上继续开发，或者将主干视为稳定版本，定期将其标记为发布，并在分支中进行实验工作。人们认为箱子是“黄金”还是“沙箱”？

Answer 1

我已经在大型商业应用中尝试过这两种方法。

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

总体上更好的方法(根据我的经验):躯干应该始终稳定。

以下是此方法的一些准则和优点:

• 在其自己的分支中对每个任务(或相关的任务集)进行编码，然后您就可以灵活地合并这些任务并执行发布。
• 在将每个分支合并到主干之前，应该对其进行质量检查。
• 通过对每个单独的分支进行质量检查，您将更容易准确地知道导致错误的原因。
• 该解决方案可扩展到任意数量的开发人员。
• 此方法有效，因为分支在 SVN 中几乎是即时操作。
• 标记您执行的每个版本。
• 您可以开发暂时不打算发布的功能，并准确决定何时合并它们。
• 对于您所做的所有工作，您都可以从提交代码中受益。如果您仅在主干外工作，您的代码可能会经常保持未提交状态，因此不 protected 且没有自动历史记录。

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

• 日常构建中不断出现的构建问题
• 当开发人员为项目中的所有其他人带来问题时，生产力会下降
• 发布周期更长，因为您最终需要获得稳定的版本
• 不太稳定的版本

如果您尝试保持分支稳定并将主干作为开发沙箱，那么您将根本无法获得所需的灵 active 。原因是您无法从主干中挑选要放入稳定版本的内容。它已经在后备箱中混合在一起了。

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

<小时/>

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