“特征分支”是指每个功能都在自己的分支中开发，只有在经过测试并准备好交付后才合并到主线中。这允许产品所有者选择进入给定发货的功能，并在出现更重要的工作时“保留”部分已编写的功能（例如，客户打电话给 MD 投诉）。
“重构”正在改造代码以改进其设计，从而降低变更成本。如果不不断这样做，您往往会得到更丑陋的代码库，这更难以为其编写测试。
现实生活中总有这样的顾客sold新功能和由于政治原因所有客户都必须看到“他们的”功能组正在取得进展。因此，很少有时候分支上没有大量半成品功能。
如果进行了任何重构，“功能分支”中的合并即使不是不可能，也会变得更加困难。
我们是否必须放弃进行任何重构？
也可以看看 ”您如何处理重构和合并需求之间的紧张关系 https://stackoverflow.com/questions/200757/how-do-you-handle-the-tension-between-refactoring-and-the-need-for-merging?rq=1?"
我这些天的看法是，由于政治原因导致这些分支机构长期存在，以及开发总监的权力被剥夺，导致他无法采取行动，我应该更快地开始寻找新工作。
功能分支肯定会让重构变得更加困难。它们还使持续集成和部署等事情变得更加困难，因为需要构建和测试的并行开发流的数量不断增加。您还回避了“持续集成”的中心原则——每个人都在相同的代码库上工作，并“持续”地将他们的更改与团队其他成员的更改集成。通常，当使用功能分支时，功能分支不会持续构建或测试，因此“功能分支”代码第一次在生产构建/测试/部署过程中运行是在它“完成”并合并时进入后备箱。这可能会在开发过程的后期和关键阶段引入一系列问题。
我持有有争议的观点你应该不惜一切代价避免功能分支。合并的成本非常高，（或许更重要的是）未能“持续集成”到共享代码库的机会成本甚至更高。
在您的场景中，您确定需要为每个客户端的功能建立一个单独的功能分支吗？您是否可以在主干中开发这些功能，但在它们准备好之前将其禁用？一般来说，我认为最好以这种方式开发“功能”——即使它们还没有准备好生产，也将它们签入主干，但在它们准备好之前将它们保留在应用程序之外。这种做法还鼓励您保持组件的良好分解并屏蔽在精心设计的接口后面。 “功能分支”方法为您提供了在代码库中进行彻底更改以实现新功能的借口。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
