我的开发团队已经使用颠覆工作了很长一段时间.管理主干和分支的方式如下:
我们(几乎)总是从行李箱中释放出来
每个版本都有自己的分支.
当一个版本准备好QA时,我们将分支合并回主干并为下一个版本创建一个新分支.
开发人员可以使用主干或分支,但是没有特定于开发人员的分支.
最近,我们有一些噩梦合并会议,部分是由于应用程序的一些重大变化.这些并不总是顺利进行,并且在QA期间有时弹出问题,其中颠覆并没有完全合并.
一种解决方案可能是定期将主干更改合并到发布分支中,例如每周一次,以确保最新的主干更改位于分支中.然后可以更接近实时地修复冲突.
您对此问题的体验是什么？有标准的最佳做法吗？此外,你有一个很好的方法来跟踪哪些修订已合并到分支(subversion中的体面评论可能会处理).
首先,在管理代码分支和发布时,我认为没有一个适合所有解决方案.但是从我的角度来谈谈你的一些观点:
是的,我会更频繁地将更改从trunk更新到发布分支.较小的块总是比一个大型集成更易于管理.当然,这意味着您正在使用最新的最稳定的代码.
主动教人们如何合并.进行更改的开发人员应该正在进行(或密切参与)合并.了解它正在采取什么以及它完成后应该是什么样子.我经常看到人们在不知道他们正在做什么以及他们期望的结果的情况下进行集成.
也许你想要一个不是主干的集成分支.这可以每天进行测试,任何问题都会在他们去之前发现并打破主干并吓跑每个人.
所以假设我的模型就在这里:你在一个分支(从主干上)开始对项目进行重大更改,这可能会变得很旧.
您继续在主干上进行其他开发,它始终包含"实时"软件,因此这些更改是次要更新和错误修复.当您将纪念性开发分支合并回主干时,您会遇到问题.
您只能使用该模型有效地管理2个并发产品版本,这可能已经足够了,但无论如何可能会以其他方式咬你,如果你需要管理3个或4个版本,会变得更糟.我可以建议改变你的工作方式吗？
为每个版本都有一个版本分支.这应该从trunk(在任何修订版本)分支.修改版本分支的唯一方法是合并trunk中的修订版.
这意味着您可以主要在主干上工作,而不是在大型开发分支中工作.您还可以将错误修复直接应用于主干 - 因此您没有为下一个版本存储重大集成问题.要发布以前版本的错误修复,只需将所需的主干修订合并到相应的版本分支中.
通过这种方式,您可以保留要在分支中发布的所有内容,但实际上只能释放您满意的内容,因为这是您合并到版本分支的所有内容.
如果需要,您仍然可以使用开发分支,但是您可以保持它们的目标和小,可能是单个功能而不是大型项目.
这将允许您以一种理智的方式管理多个版本,并使用svn的merge-info跟踪每个版本中的内容.
我们的经验是明确区分:
发展部门
合并分支(用于整合开发的分支机构,我们一定会投入生产
Trunk仅用于记录稳定发布的版本,我们可以从中分支.
在"开发分支"中,我们可以管理重要的更改,包括一些不会在下一个版本中结束的更改(因为太复杂,没有及时准备,取决于其他后期开发,......)
合并分支代表完成发布所需的最后步骤(注意复数).它发生在会议之后,需要交付的所有功能都经过验证.
我们只合并到"合并分支",我们肯定会投入生产.我们继续该分支,直到最终版本.
京公网安备 11010802040832号 | 京ICP备19059560号-6 