Subversion分支/主干最佳实践——让分支保持最新状态?

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

• 也许你想有一个不是主干的集成分支。这可以每天进行测试,在他们去打破后备箱并吓到每个人之前,这里发现的任何问题都可以进行测试。

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

使用该模型,您只能有效地管理2个并发的产品版本,这目前可能已经足够了,但无论如何都可能以其他方式影响您,如果您需要管理3个或4个版本,情况会变得更糟。我可以建议你颠倒一下工作方式吗?

这样,您可以将所有想要发布的内容保存在分支中,但实际上只发布您满意的内容,因为这就是您合并到版本分支中的全部内容。

如果需要,您仍然可以使用开发分支,但您可以保持它们的针对性和小型,也许是单个功能,而不是大型项目。

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

我们的经验是明确区分:

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

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

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

完全同意Andy的观点:没有“一刀切的解决方案”,但问题不应该是让你的发布分支保持最新,相反。

良好的变更控制应该可以防止您的分支不稳定。门控问题应在发布分支上修复,然后立即合并到主干中。准备好让这种“合并”变得不平凡,释放门控问题甚至可能不存在于主干上,但无论如何你都需要对其进行分析和测试。

从你所说的听起来,你正在树枝上发育,然后在释放之前,交叉手指,一次合并到树干上。我想知道你这样做会引入多少bug。

首先,我完全同意前面的回应者的观点,即没有一刀切的解决方案。

在我们的例子中,我们有许多相对较小的应用程序,每个应用程序通常只有一个开发人员。当我们进行协作开发时,往往只有2到4名开发人员。

• 主干包含当前项目状态;
• 为了释放,我们从当前主干创建一个标签并释放该标签。

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