svn工作流程

一般来说,工作流通常是为特定的团队/项目定制的。

我的工作流程如下:

• 为产品的所有发布版本创建分支。热修复和小更新在分支中完成(然后构建、测试并交付给最终用户)。类似的修复也提交给trunk(或者稍后从branch合并)。

• 当一组开发人员完成功能开发时,有时会为大型功能创建单独的分支,并且/或者可能会对其他开发人员产生重大影响。这种方法的优点值得怀疑,而且取决于具体的情况,因为SVN中的合并过程有时很昂贵。

• 开发人员的机器只保留工作副本,而版本开发人员目前正在处理。开发人员经常更新,并修复所有冲突。此外,开发人员经常使用准备好的代码进行提交。

• 产品被频繁地构建和测试-这允许尽快发现新引入的bug。

合并过程在SVN中相当昂贵。进一步的工作流程复杂性 可以 导致痛苦的融合。顺便说一句,有些团队成功地解决了这个问题。

我建议您也来看看分布式版本控制系统。Joel Spolsky的这篇文章很好地描述了它们的主要优势: http://www.joelonsoftware.com/items/2010/03/17.html

回答你的特殊问题,我可以建议如下(顺便说一句,我看不到整个开发过程,所以这可能不适用):

• 当产品被接受发布时,将创建新的分支。此版本安装在生产服务器上。

• 在后备箱中也进行了进一步的产品开发。

主干通常(但并不总是)表示在正常开发过程中每个人都参与的主线活动代码基。分支是通过分叉主干(或其他分支)创建的。Subversion对此的支持不是很好(即使在最近几年解决了一些主要的问题之后),而且大多数团队都避免这样做,这不幸意味着他们通常会被困在主干上完成所有工作。

您可以使用的一种实用方法是在每次发布时创建一个发布分支。这允许团队继续在主干上开发产品,而支持人员可以在新分支上修复发布产品的bug。这通常可以正常工作,因为在trunk和当前发布分支之间没有太多的合并活动,而且如果有,它在本质上很少是结构化的(移动、重命名等,对Subversion中的分支和合并有可怕的影响)。