Subversion分支/主干最佳实践-使分支保持最新?

• 是的,我会更频繁地将主干中的更改合并到发布分支中。较小的块总是比一个大型集成更易于管理。当然,这意味着您正在使用最新最稳定的代码。

• 主动教人们如何很好地融合。进行更改的开发人员应该进行(或密切参与)合并。了解你正在服用的是什么,以及服用完毕后应该是什么样子。我经常看到人们在不知道自己在做什么和期望结果的情况下运行集成。

• 也许您希望有一个不是主干的集成分支。这可以每天测试,任何问题都可以在他们去打破树干和吓唬每个人之前被发现。

因此,假设我这里有你的模型:你在一个分支(主干外)中对项目进行重大更改,这个分支可能会变得很旧。

您继续在trunk上进行其他开发,trunk始终保存着“实时”软件,因此这些更改只是小的更新和bug修复。 当您将不朽的开发分支合并回主干时,您会遇到问题。

使用该模型,您只能有效地管理2个并发的产品版本,这可能就足够了,但可能会在其他方面影响您,如果您需要管理3或4个版本,情况会变得更糟。我能建议你改变工作方式吗?

每个版本都有一个版本分支。这应该从主干分支(在任何版本)。

这意味着您可以主要在主干上工作,而不是在大型开发分支中工作。您还可以将错误修复直接应用到主干上,这样就不会为下一版本存储任何主要的集成问题。要对以前的版本发布bug修复,只需将所需的主干修订合并到相应的版本分支中。

通过这种方式,您可以在分支中保留您想要发布的所有内容,但实际上只发布您满意的内容,因为这就是您合并到版本分支中的所有内容。

这将允许您以合理的方式管理多个版本,并使用svn的合并信息很好地跟踪每个版本中的内容。

我们的经验是明确区分:

• 发展科
• 合并分部

Trunk只用于录制稳定的发布版本,我们可以从中进行分支。

在“开发分支”中,我们可以管理重要的更改,包括一些不会在下一版本中结束的更改(因为太复杂,没有及时准备好,依赖于其他后期开发,…)

合并分支表示完成发布所需的最后步骤(注意复数形式)。它发生在所有需要交付的功能都经过验证的会议之后。

我们只将确定投入生产的产品并入“整合部门”。我们继续这个分支,直到最终发布。

从你所说的听起来,你是在你的分支上发展,然后在你松开和交叉手指之前,一次将所有的东西合并到你的躯干上。我想知道你这样做会引入多少bug。

首先,我完全同意之前的回应者的观点,即没有一个适合所有人的解决方案。

我们的一般政策是:

• 我们使用分支来开发新功能、修复bug等。分支完成后会合并回主干;
• 为了释放,我们从当前主干创建一个标记并释放该标记。

Andy还提出了一个需要强调的重要观点:“积极主动地教人们如何很好地进行合并。”我们的许多问题(如果不是大多数的话)似乎都源于糟糕的合并实践。