分支源代码和应用程​​序生命周期的最佳实践

我们是一家ISV小型商店，通常我们每个月都会发布我们产品的新版本。我们使用Subversion作为代码存储库，并使用Visual Studio 2010作为IDE。我知道很多人都在倡导Mercurial和其他分布式源代码控制系统，但是目前我还不知道如何从中受益，但是我可能是错的。

我们的主要问题是如何使分支和主干保持同步。

这是我们今天的工作方式：

1. 发布新版本（在Subversion中自动创建标签）
2. 继续研究将于下个月发布的主干

并且该周期每个月重复一次，并且运行良好。当需要发布紧急服务发布时会出现问题。我们无法从主干（2）上将其释放，因为它正在大力开发且不够稳定，无法紧急释放。

在这种情况下，我们将执行以下操作：

1. 从我们在步骤（1）中创建的标签创建分支
2. 错误修复
3. 测试并发布
4. 将更改推回主干（如果适用）

我们最大的问题是将这两个（主分支）合并。在大多数情况下，我们不能依靠自动合并，因为例如：

• 主干做了很多改变
• 合并复杂的文件（例如Visual Studio XML文件等）效果不佳
• 另一个开发人员/团队进行了您不了解的更改，您无法将其合并

因此，您认为最好的做法是使这两个不同的版本（分支和主版本）保持同步。你是做什么？

我认为您进行分支和合并的方法是可以的，但是如果主要问题是代码库非常不稳定，那么您需要集中精力并使其最小化。

首先要确保代码库具有良好的关注点分离。需要隔离和减少各种组件之间的依赖关系。这应该可以解决您的大多数问题。遵循诸如单一责任原则之类的做法也将有所帮助。

如果需要进行重大的体系结构更改，则应在其自己的分支机构中进行更改，然后在经过充分测试和“稳定”之后（在合理的范围内）将其合并回主结构。这可能是痛苦且具有挑战性的，但也应该很少见。如果您有良好的测试实践，那么风险就可以降到最低。

更改为分布式版本控制系统也可能有所帮助。这将为您提供稳定的干线，在准备好这些功能时，它们会从不同分支合并到一起。如果代码之间的依赖关系太强，您将仍然难以合并，但是您将拥有更多的控制权。

从另一个角度看待这一点，还应考虑增加团队之间的沟通。定期举行敏捷式站立会议。考虑团队成员的位置以及如何提供帮助。如果需要进行复杂的合并，则可能不是一件坏事-使用成对编程方法可以使双方都理解。

我倾向于从相反的角度看待它：

• Trunk应该始终是可用于生产的代码（即在您的第一个初始版本之后）。
• 应该有一个与主干并行运行的开发类型分支，每月进行一次开发。每个月，发布时间都会合并到主干中，进行测试，然后发布。
• 然后可以轻松地在您的中继中进行修补程序并签入，并且始终可以成功部署。然后从该修补程序制作一个补丁，并将其应用到您的开发分支。

当然，此工作流程更适合于非SVN的内容，因为无论您的工作流程如何，良好的分支和合并都是SVN中非常痛苦的事情。以我的经验，几乎应该总是手动完成SVN的合并，因为这是行不通的，并且没有真正的解决方法。

最近，我一直在倡导“分支和合并”的哲学，这是最后的结果。我认为不幸的是，处理来自分支的代码合并不是一个技术问题，但这是一项任务，从认知上来说是困难的：我认为这仅仅是因为人类的大脑没有跟踪足够的细节来使它变得容易。而且，我还没有看到分支和合并实际上在实践中起作用。一旦代码被分支，经验告诉我，除了再次合并它，无非是麻烦。

纪律严明的主发布方式效果很好。

SVN分支的设计不灵活。我建议您的第一个问题在于SVN；从那开始将打开新的选择。