问您是在分支还是在主干中继续开发？

EN

我已经在一个大型商业应用程序中尝试了这两种方法。

哪种方法更好的答案在很大程度上取决于你的实际情况，但我将写下我到目前为止的总体经验。

总体上更好的方法(根据我的经验)：主干应该总是稳定的。

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

• 在自己的分支中对每个任务(或相关任务集)进行编码，然后您将可以灵活地选择何时合并这些任务并执行发布。在将每个分支合并到干线之前，应对每个分支执行
• QA。
• 通过在每个单独的分支上执行QA，您将确切地了解导致错误的原因。
• 此解决方案可扩展到任何数量的开发人员。
• 此方法有效，因为分支在SVN中几乎是即时操作。
• 标记您执行的每个版本。
• 您可以开发暂时不打算发布的功能，并确切地决定何时合并它们。
• 对于您所做的所有工作，您都可以从提交代码中获益。如果你只在主干之外工作，你可能会保持你的代码大量未提交，因此没有保护，没有自动历史记录。

如果你试图做相反的事情，并在主干中完成所有的开发，你将会遇到以下问题：

当开发人员在project

• Longer发布周期中为所有其他人提交问题时，
• 每天都会出现持续的构建问题，因为您需要最终获得稳定的版本
• 不太稳定的版本

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

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

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

我使用过这两种技术，我想说的是，在主干上开发，并在发布时分支出稳定的点是最好的方法。

上面那些人反对说你会有：

• 日常构建的持续构建问题当开发人员为项目

中的所有其他人提交问题时，

• 生产力损失

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

诚然，如果你不在一天中执行几次测试构建，比如说每小时一次，就会让自己暴露在这些问题面前，这将很快扼杀开发的步伐。

在一天中做几个测试构建会快速地将更新折叠到主代码库中，以便其他人可以使用它，如果有人破坏了构建，还会在一天中提醒您，以便他们可以在回家之前修复它。

正如所指出的，只有在用于运行回归测试的夜间构建失败时才能发现损坏的构建，这是完全愚蠢的，并且会很快减慢速度。

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

我倾向于采用“发布分支”的方法。主干是不稳定的。一旦发布时间临近，我会创建一个发布分支，我会更加谨慎地对待它。当最终完成时，我会标记/标记存储库的状态，这样我就可以知道“官方”发布的版本。

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