您是在分支中还是在主干中继续开发?

假设您正在开发一个定期发布的软件产品。关于分支和合并的最佳实践是什么?将定期发布的分支切分给公众(或您的客户是谁),然后在主干上继续开发,或者将主干视为稳定版本,定期将其标记为发布,并在分支中进行实验工作。人们认为行李箱是“黄金”还是“沙盒”?

请先 登录 后评论

8 个回答

17 of 26

主干线一般是主要的开发线。

版本是分支的,通常在分支上完成实验或主要工作,然后在准备好与主开发线集成时合并回主干。

请先 登录 后评论
Matt Dillard

我倾向于采用“发布分支”的方法。树干是易变的。一旦发布时间临近,我会创建一个发布分支,我会更加谨慎地对待它。当这最终完成时,我会标记/标记存储库的状态,以便我知道“官方”发布的版本。

我知道还有其他方法可以做到这一点 - 这正是我过去的做法。

请先 登录 后评论
Jon Limjap

我认为你的第二种方法(例如,标记版本和在分支中做实验性的东西,考虑到主干稳定)是最好的方法。

应该清楚的是,分支在分支时继承了系统的所有错误:如果将修复应用于主干,如果您将分支维护为一种发布周期终结者。如果您已经发布了 20 个版本,并且发现了一个可以追溯到第一个版本的错误,那么您必须重新应用您的修复 20 次。

分支应该是真正的沙箱,虽然主干也必须扮演这个角色:标签会指示代码在那个时间点是否“黄金”,适合发布。

请先 登录 后评论
Jim

主干通常应该是您的主要开发源。否则,您将花费大量时间合并新功能。我已经看到它以另一种方式完成,它通常会导致很多最后一分钟的集成问题。

我们标记我们的发布,以便我们可以快速响应生产紧急情况而无需分发积极的开发。

请先 登录 后评论
Chuck

尝试根据新开发管理当前生产代码的维护充其量是有问题的。为了缓解这些问题,一旦测试工作完成并且代码准备好交付,代码应该分支到维护行。此外,主线应该分支以帮助稳定版本,包含实验性开发工作,或容纳生命周期跨越多个版本的任何开发工作。

仅当代码之间存在冲突的可能性(或确定性)而难以以任何其他方式管理时,才应创建非维护分支。如果分支机构没有解决后勤问题,它将创建一个。

正常发布开发发生在主线中。开发人员签入和签出主线以进行正常的发布工作。当前生产代码的补丁开发工作应该在该版本的分支中,然后在补丁通过测试并部署后与主线合并。非维护部门的工作应根据具体情况进行协调。

请先 登录 后评论
cpm

对我来说,这取决于我使用的软件。

在 CVS 下,我只会在“主干”中工作,从不标记/分支,因为否则真的很痛苦。

在 SVN 中,我会在主干中做“最前沿”的工作,但是当需要进行服务器推送时,会得到适当的标记。

我最近切换到 git。现在我发现我从不在后备箱工作。相反,我使用了一个名为“new-featurename”的沙箱分支,然后合并到一个固定的“current-production”分支中。现在我想起来了,我真的应该在合并回“当前生产”之前创建“release-VERSIONNUMBER”分支,这样我就可以回到旧的稳定版本......

请先 登录 后评论
Josh Segall

这取决于你的情况。我们使用 Perforce,通常有几条开发线。主干被认为是“黄金”,所有开发都发生在分支上,当它们足够稳定可以集成时,它们会合并回主线。这允许拒绝不合格的功能,并且可以随着时间的推移提供独立的项目/功能可以采用的可靠增量功能。

合并和赶上主干中的新功能需要集成成本,但无论如何您都会遭受这种痛苦。让每个人都在主干上一起发展可能会导致狂野的西部局势,而分支可以让您扩展并选择您想要服用苦涩整合药丸的点。目前,我们在十几个项目中拥有超过一百名开发人员,每个项目都有多个使用相同核心组件的版本,而且运行良好。

这样做的好处在于您可以递归地执行此操作:一个大的功能分支可以是它自己的主干,如果它其他分支就会脱落。此外,最终版本会获得一个新分支,为您提供进行稳定维护的地方。

请先 登录 后评论
DevelopingChris

如果你要完成一个发布周期、一个大功能,你就会被困在一个分支上。否则,我们在主干中工作,并在我们构建时为每个生产版本分支。

当时以前的生产版本已移至 old_production_,而当前的产品版本始终只是生产版本。我们的构建服务器所知道的关于生产的所有信息都是如何部署生产分支,并且我们通过强制触发器启动该构建。

请先 登录 后评论