假设您正在开发定期发布的软件产品.在分支和合并方面有哪些最佳实践？将定期发布分支机构切换到公众(或任何客户),然后继续在主干上进行开发,或者考虑使用稳定版本的主干,定期将其标记为发布,并在分支机构中进行实验性工作.人们认为树干被认为是"黄金"还是被认为是"沙箱"？
我已经尝试了两种方法与大型商业应用程序.
哪种方法更好的答案在很大程度上取决于你的具体情况,但我会写出我迄今为止的总体经验.
整体上更好的方法(根据我的经验):树干应该始终稳定.
以下是此方法的一些指导原则和好处:
在自己的分支中对每个任务(或相关的任务集)进行编码,然后您就可以灵活地合并这些任务并执行发布.
QA应该在每个分支合并到主干之前完成.
通过在每个分支上执行QA,您将确切地知道导致错误的原因.
该解决方案适用于任何数量的开发人员.
这种方法有效,因为分支在SVN中几乎是即时操作.
标记您执行的每个版本.
您可以开发一段时间不打算发布的功能,并确定何时合并它们.
对于您所做的所有工作,您可以享受提交代码的好处.如果你只在干线上工作,你可能会保持你的代码不被提交很多,因此没有保护,没有自动历史记录.
如果您尝试执行相反操作并在主干中进行所有开发,则会出现以下问题:
每日构建的持续构建问题
当开发人员为项目中的所有其他人提出问题时,生产力会下降
更长的发布周期,因为你需要最终得到一个稳定的版本
不太稳定的版本
如果您尝试保持分支稳定并将主干作为开发沙箱,那么您将无法获得所需的灵活性.原因是你不能从主干中挑选你想要放在那个稳定版本中的东西.它已经全部混合在一起了.
特别是我要说在后备箱中进行所有开发的一个案例是当你开始一个新项目时.根据您的情况,可能还有其他情况.
顺便说一句,分布式版本控制系统提供了更大的灵活性,我强烈建议切换到hg或git.
我已经使用了这两种技术,我会说在后备箱上进行开发并在稳定点上分支,因为发布是最好的方法.
那些反对说你会拥有的人:
每日构建的持续构建问题
当开发人员为项目中的所有其他人提出问题时,生产力会下降
可能没有使用持续集成技术.
确实,如果你不在白天进行多次测试,比如说每小时左右一次,就会对这些问题开放,这会迅速扼杀发展的步伐.
在白天进行多次测试构建会快速折叠主代码库的更新,以便其他人可以使用它,并在白天提醒您,如果有人打破了构建,以便他们可以在回家之前修复它.
正如所指出的那样,只有在运行回归测试的每晚构建失败时才发现有关破坏的构建是完全愚蠢的,并且会很快减慢速度.
阅读Martin Fowler关于持续集成的论文.我们在大约2,000行Posix sh中为一个主要项目(3,000kSLOC)推出了我们自己的系统.
我倾向于采用"发布分支"的方法.行李箱很不稳定.一旦发布时间临近,我会发布一个发布分支,我会更谨慎地对待它.当它最终完成时,我会标记/标记存储库的状态,以便我知道"官方"发布的版本.
我知道还有其他方法可以做到 - 这就是我过去做过的方式.
都.
主干用于大部分开发.但预计将尽最大努力确保对行李箱的任何登记都不会破坏它.(由自动构建和测试系统部分验证)
发布版本保存在自己的目录中,只对它们进行了错误修复(然后合并到主干中).
任何将使主干处于不稳定或非工作状态的新功能都在其自己的独立分支中完成,然后在完成时合并到主干中.
我喜欢并使用Henrik Kniberg在多重敏捷团队版本控制中描述的方法.Henrik在解释如何在多个团队的敏捷环境中处理版本控制方面做得非常出色(在传统环境中也适用于单个团队)并且没有任何意义解释他所以我只会发布"备忘单"(其中是自我解释)下面:
我喜欢它因为:
这很简单:你可以从图片中得到它.
它可以很好地工作(并且可以扩展)而不会出现太多的合并和冲突问题.
您可以随时发布"工作软件"(本着敏捷的精神).
并且万一它不够明确:开发在"工作分支"中完成,主干用于DONE(可释放)代码.检查多个敏捷团队的版本控制以获取所有详细信息.
Divmod的终极质量开发系统是一个很好的参考,可以保证干线稳定并且所有功能都在分支机构中运行.快速摘要:
所有完成的工作必须有一张与之相关的票
为每个票证创建一个新分支,完成该票证的工作
来自该分支的更改不会合并回主线主干,而不会被其他项目成员审核
他们使用SVN,但这可以通过任何分布式版本控制系统轻松完成.
我认为你的第二种方法(例如,标记发布和在分支中做实验性的东西,考虑到主干稳定)是最好的方法.
应该清楚的是,分支在它被分支的时间点继承了系统的所有错误:如果修复应用于主干,如果你将分支作为一种分支保存,你将不得不一个接一个地去所有分支.发布周期终结器.如果您已经有20个版本并且发现了一个可以追溯到第一个版本的错误,那么您将不得不重新应用修复20次.
分支应该是真正的沙箱,虽然主干也必须扮演这个角色:标签将指示代码在那个时间点是否为"黄金",适合发布.
我们在行李箱上开发,除非变化太大,不稳定,或者我们正在接近我们的一个产品的主要版本,在这种情况下我们创建一个临时分支.我们还为每个产品发布创建一个永久分支.我发现微软关于分支指导的文档非常有帮助.Eric Sink 关于分支的教程也很有趣,并指出对微软有用的东西可能对我们其他人来说太沉重了.在我们的例子中,我们实际上使用了Eric所说的团队所做的方法.
这取决于你的情况.我们使用Perforce并且通常有几行开发.主干被认为是"黄金",所有开发都发生在分支上,当它们足够稳定以便整合时,它们会合并回主线.这允许拒绝不进行切割的功能,并且可以随着时间的推移提供独立项目/功能可以提取的可靠增量功能.
合并和追赶到主干的新功能有集成成本,但无论如何你都会遭受这种痛苦.让每个人在后备箱上一起发展可以导致狂野的西部情况,而分支允许你扩展并选择你想要服用苦味集成药丸的点.我们目前已经在十几个项目中扩展到了一百多个开发人员,每个项目都有多个使用相同核心组件的版本,并且它运行良好.
这样做的好处在于你可以递归地执行此操作:一个大的功能分支可以是它自己的主干,如果有其他分支就会脱落.此外,最终版本将获得一个新分支,为您提供稳定维护的地方.
京公网安备 11010802040832号 | 京ICP备19059560号-6 