“功能分支”是指每个功能都在自己的分支中开发，并且只有在经过测试并准备好发布时才合并到主线中。这允许产品所有者选择进入给定 cargo 的功能，并在更重要的工作进入时“停放”部分编写的功能(例如，客户调用 MD 提示)。
“重构”正在转换代码以改进其设计，以降低更改成本。如果不不断地这样做，您往往会得到更难写的代码库，更难编写测试。
在现实生活中，总有一些客户是已售出新功能和 由于政治所有客户都必须看到“他们的”功能组正在取得进展。所以很少有时间没有很多半成品的功能坐在 Twig 上。
如果进行了任何重构，那么“功能分支”中的合并会变得更加困难，如果不是不可能的话。
我们是否必须放弃能够进行任何重构？
另见“How do you handle the tension between refactoring and the need for merging？”
这些天我的观点是，由于政治原因导致了这些长期存在的分支机构以及开发总监的权力被剥夺而无法采取行动，我应该更快地开始寻找新工作。
最佳答案
特性分支无疑使重构变得更加困难。它们还使持续集成和部署等事情变得更加困难，因为您正在增加需要构建和测试的并行开发流的数量。您还消除了“持续集成”的中心原则——每个人都在同一个代码库上工作，并“持续地”将他们的更改与团队的其他更改集成。通常，在使用特性分支时，特性分支不会持续构建或测试，因此“特性分支”代码第一次通过生产构建/测试/部署过程运行是在它“完成”并合并时进入后备箱。这可能会在开发过程的后期和关键阶段引入大量问题。
我持有有争议的观点您应该(几乎)不惜一切代价避免功能分支 .合并的成本非常高，而且(也许更重要的是)未能“持续集成”到共享代码库中的机会成本甚至更高。
在您的场景中，您确定每个客户的功能都需要一个单独的功能分支吗？您是否可以改为在后备箱中开发这些功能，但在它们准备好之前将它们禁用？一般来说，我认为以这种方式开发“功能”更好——即使它们还没有准备好生产，也将它们 checkin 到主干中，但在它们准备好之前将它们留在应用程序之外。这种做法还鼓励您在精心设计的界面后面保持组件的良好分解和屏蔽。 “功能分支”方法为您提供了对代码库进行全面更改以实现新功能的借口。
关于version-control - 使用 “feature branches” 与重构兼容吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4044362/