您是继续在分支机构还是在后备箱中进行开发？
假设您正在开发定期发布的软件产品.在分支和合并方面有哪些最佳实践？将定期发布分支机构切换到公众(或任何客户),然后继续在主干上进行开发,或者考虑使用稳定版本的主干,定期将其标记为发布,并在分支机构中进行实验性工作.人们认为树干被认为是"黄金"还是被认为是"沙箱"？
Bri*_*ndy 151
我已经尝试了两种方法与大型商业应用程序.
哪种方法更好的答案在很大程度上取决于你的具体情况,但我会写出我迄今为止的总体经验.
整体上更好的方法(根据我的经验):树干应该始终稳定.
以下是此方法的一些指导原则和好处:
- 在自己的分支中对每个任务(或相关的任务集)进行编码,然后您就可以灵活地合并这些任务并执行发布.
- QA应该在每个分支合并到主干之前完成.
- 通过在每个分支上执行QA,您将确切地知道导致错误的原因.
- 该解决方案适用于任何数量的开发人员.
- 这种方法有效,因为分支在SVN中几乎是即时操作.
- 标记您执行的每个版本.
- 您可以开发一段时间不打算发布的功能,并确定何时合并它们.
- 对于您所做的所有工作,您可以享受提交代码的好处.如果你只在干线上工作,你可能会保持你的代码不被提交很多,因此没有保护,没有自动历史记录.
如果您尝试执行相反操作并在主干中进行所有开发,则会出现以下问题:
- 每日构建的持续构建问题
- 当开发人员为项目中的所有其他人提出问题时,生产力会下降
- 更长的发布周期,因为你需要最终得到一个稳定的版本
- 不太稳定的版本
如果您尝试保持分支稳定并将主干作为开发沙箱,那么您将无法获得所需的灵活性.原因是你不能从主干中挑选你想要放在那个稳定版本中的东西.它已经全部混合在一起了.
特别是我要说在后备箱中进行所有开发的一个案例是当你开始一个新项目时.根据您的情况,可能还有其他情况.
顺便说一句,分布式版本控制系统提供了更大的灵活性,我强烈建议切换到hg或git.
- 我没有声称这是唯一的方式,只是这是更好的方式.当然,如果你认为你有足够的理由认为我错了,那么你应该发布它.至少我的答案是合理的. (52认同)
- 对不起,但这个答案是对的.所有的开发都应该在后备箱中进行.如果您有某些"尖峰"或某些"冒险"功能,请创建一个功能分支.应该为生产中的每个版本的产品维护分支,或者如果存在单个版本,则使用Integration分支. (35认同)
- 在回应Mnementh的帖子时,我认为一个好的解决方案是开发人员应该定期将主干合并到他们的分支中,这样他们就不会离开主干的状态太远.每个开发人员都应该经常这样做,以便他们在任何时候都不会出现巨大的重返社会问题. (31认同)
- @Mnementh这不是借口.最佳实践和常识是团队中的每个人都应该使用主干更新他们的分支机构.主线主干不是完美的,也不是你想要的产品,它只需要编译,这就是为什么在良好的开发环境中,大多数开发人员非常擅长确保这种情况发生,如果没有,团队有权给那个人一个艰难的时间......还有Cruise Control和其他连续构建设置等工具.这就是持续整合的全部意义所在!您有QA测试您的分支机构而不是您的主干线路. (8认同)
- 这是有问题的,因为开发人员可以在与主干分叉的分支上长时间工作.稍后整合这些东西会产生很大的麻烦.对我来说,保持一个具有一些最低要求(必须始终编译)的出血边干线总是更容易,并且对于应该稳定以释放的东西的分支来说总是更容易. (5认同)
- 此方法对数据库应用程序只有一个问题.添加到分支,合并到主干并在生产数据库上执行的SQL迁移脚本必须按创建顺序执行.功能分支有什么困难. (2认同)
- @Mitch:没有正确或错误的方法. (2认同)
Rob*_*lls 66
我已经使用了这两种技术,我会说在后备箱上进行开发并在稳定点上分支,因为发布是最好的方法.
那些反对说你会拥有的人:
- 每日构建的持续构建问题
- 当开发人员为项目中的所有其他人提出问题时,生产力会下降
可能没有使用持续集成技术.
确实,如果你不在白天进行多次测试,比如说每小时左右一次,就会对这些问题开放,这会迅速扼杀发展的步伐.
在白天进行多次测试构建会快速折叠主代码库的更新,以便其他人可以使用它,并在白天提醒您,如果有人打破了构建,以便他们可以在回家之前修复它.
正如所指出的那样,只有在运行回归测试的每晚构建失败时才发现有关破坏的构建是完全愚蠢的,并且会很快减慢速度.
阅读Martin Fowler关于持续集成的论文.我们在大约2,000行Posix sh中为一个主要项目(3,000kSLOC)推出了我们自己的系统.
- @Jeach,每天进行多次构建可以让您自信地构建它,以便您可以定期运行测试,可以在白天进行简单的smkoke测试,也可以在晚上进行回归测试.如果您将构建保留到晚上的构建以进行回归测试,则可以将整个项目设置为一天,因为您无法构建.这意味着所有开发人员都无法查看他们提交的新代码的回归测试结果.相当昂贵的成本,仅仅因为,例如,某人签入了包含语法错误的代码. (2认同)
Mat*_*ard 36
我倾向于采用"发布分支"的方法.行李箱很不稳定.一旦发布时间临近,我会发布一个发布分支,我会更谨慎地对待它.当它最终完成时,我会标记/标记存储库的状态,以便我知道"官方"发布的版本.
我知道还有其他方法可以做到 - 这就是我过去做过的方式.
And*_*mbe 19
都.
主干用于大部分开发.但预计将尽最大努力确保对行李箱的任何登记都不会破坏它.(由自动构建和测试系统部分验证)
发布版本保存在自己的目录中,只对它们进行了错误修复(然后合并到主干中).
任何将使主干处于不稳定或非工作状态的新功能都在其自己的独立分支中完成,然后在完成时合并到主干中.
- 我和你在一起......开发人员一直只坚持一种方法就是问题! (3认同)
Pas*_*ent 14
我喜欢并使用Henrik Kniberg在多重敏捷团队版本控制中描述的方法.Henrik在解释如何在多个团队的敏捷环境中处理版本控制方面做得非常出色(在传统环境中也适用于单个团队)并且没有任何意义解释他所以我只会发布"备忘单"(其中是自我解释)下面:
我喜欢它因为:
- 这很简单:你可以从图片中得到它.
- 它可以很好地工作(并且可以扩展)而不会出现太多的合并和冲突问题.
- 您可以随时发布"工作软件"(本着敏捷的精神).
并且万一它不够明确:开发在"工作分支"中完成,主干用于DONE(可释放)代码.检查多个敏捷团队的版本控制以获取所有详细信息.
Jon*_*jap 10
我认为你的第二种方法(例如,标记发布和在分支中做实验性的东西,考虑到主干稳定)是最好的方法.
应该清楚的是,分支在它被分支的时间点继承了系统的所有错误:如果修复应用于主干,如果你将分支作为一种分支保存,你将不得不一个接一个地去所有分支.发布周期终结器.如果您已经有20个版本并且发现了一个可以追溯到第一个版本的错误,那么您将不得不重新应用修复20次.
分支应该是真正的沙箱,虽然主干也必须扮演这个角色:标签将指示代码在那个时间点是否为"黄金",适合发布.
这取决于你的情况.我们使用Perforce并且通常有几行开发.主干被认为是"黄金",所有开发都发生在分支上,当它们足够稳定以便整合时,它们会合并回主线.这允许拒绝不进行切割的功能,并且可以随着时间的推移提供独立项目/功能可以提取的可靠增量功能.
合并和追赶到主干的新功能有集成成本,但无论如何你都会遭受这种痛苦.让每个人在后备箱上一起发展可以导致狂野的西部情况,而分支允许你扩展并选择你想要服用苦味集成药丸的点.我们目前已经在十几个项目中扩展到了一百多个开发人员,每个项目都有多个使用相同核心组件的版本,并且它运行良好.
这样做的好处在于你可以递归地执行此操作:一个大的功能分支可以是它自己的主干,如果有其他分支就会脱落.此外,最终版本将获得一个新分支,为您提供稳定维护的地方.