使用"功能分支"与重构兼容吗？

Ian*_*ose 22 version-control refactoring branch feature-branch

" 特征分支 " 是指每个特征在其自己的分支中开发,并且仅在经过测试并准备发运时才合并到主线中.这允许产品所有者选择进入给定货件的功能以及如果更重要的工作进入而部分写入的"停放"功能(例如,客户打电话给MD进行投诉).

" 重构 "正在改变代码以改进其设计,从而降低变更成本.如果不继续这样做,你往往会得到更难以编写测试的代码库.

在现实生活中,总会有客户销售新功能,并且由于政治原因,所有客户都必须看到"他们的"功能组正在取得进展.因此很少有时间没有很多半成品功能坐在树枝上.

如果已经进行了任何重构,那么"特征分支"中的合并变得更加困难,如果不是不可能的话.

我们只是不得不放弃能够进行任何重构吗？

功能分支肯定会使重构变得更加困难.它们还使得持续集成和部署更加困难,因为您需要构建经过测试的并行开发流的数量不断膨胀.您也正在消除"持续集成"的核心原则 - 每个人都在使用相同的代码库,并"不断"将他们的更改与团队的其他变更集成在一起.通常,在使用功能分支时,功能分支不会持续构建或测试,因此"功能分支"代码第一次通过生产构建/测试/部署过程运行时,它是"完成"并合并进入行李箱.这可能会在开发过程的后期和关键阶段引入一系列问题.

我持有有争议的意见,你应该(几乎)所有成本避免功能分支.合并的成本非常高,并且(或许更重要的是)未能"持续集成"到共享代码库中的机会成本甚至更高.

在您的方案中,您确定每个客户端的功能都需要单独的功能分支吗？您是否可以在后备箱中开发这些功能但是在它们准备好之前将它们禁用？一般来说,我认为以这种方式开发"功能"更好 - 即使它们不是生产就绪,也要检查它们,但是在它们准备就绪之前将它们从应用程序中删除.这种做法还鼓励您将您的组件保持良好的分解并屏蔽设计良好的接口."功能分支"方法为您提供了在代码库中进行全面更改以实现新功能的借口.

你们肯定是合适的,在某些工具(git,mercurial,accurev)中合并比在其他工具(svn)中更容易.但是,即使合并很简单(它永远也不会),您仍然会将并行代码行分开,直到"大合并"发生.与此相关的成本 - 您的团队不会像在单一代码行上那样快速地共享和集成.特征分支从根本上打破了"持续集成"的原则,其具有许多已证明的好处. (3认同)

man*_*ana 10

我喜欢这个引人深思的论文('放弃重构'),因为它丰富了讨论:)

我同意在拥有大量并行代码时必须非常小心更大的重构,因为冲突可能会大大增加集成工作,甚至会导致在合并期间引入回归错误.

由于这一点,重构与功能分支问题,有很多权衡.因此,我根据具体情况决定:

在功能分支上,我只做重构,如果他们准备我的功能更容易实现.我总是试着只关注这个功能.分支应尽可能与主干/主线不同.
反过来我有时甚至有重构分支,我做更大的重构(恢复多个步骤非常容易,我不会分散我的主干同事).当然,我会告诉我的团队,我正在进行这种重构,并尝试计划在清理开发周期中执行此操作(如果您愿意,可以将其命名为sprint).
如果你提到的政治是一件大事,那么我会在内部封装重构工作并将其添加到估算中.在我看来,中间客户在获得更好的代码质量时会看到更快的进展.很可能不会理解重构(这是有道理的,因为这超出了他们的范围......),所以我把它隐藏起来
我永远不会做的是重构一个发布分支,其目标是稳定性.只允许修复错误.

总结一下,我会根据代码行计划我的重构: