Version control 正在使用“；功能分支&x201D；与重构兼容吗？

“功能分支”是指每个功能都在其自己的分支中开发，并且只有在经过测试并准备发货时才合并到主线中。这允许产品负责人选择进入给定发货的功能，如果有更重要的工作（例如，客户打电话给MD投诉），则可以“停放”部分编写的功能

“重构”是对代码进行转换，以改进其设计，从而降低更改成本。如果不不断地这样做，您往往会得到更难看的代码库，而编写测试就更困难

在现实生活中，总有一些客户因为政治原因被出售了新功能，所有客户都必须看到“他们的”功能组正在取得进展。因此，很少有一段时间分支上没有很多未完成的特性

如果进行了任何重构，“功能分支”中的合并即使不是不可能，也会变得更加困难

我们是否必须放弃任何重构功能？

另见“？”

---

---

这些天来，我的观点是，由于政治原因导致了这些长期存在的分支机构，并且开发总监的权力被剥夺，阻止了他采取行动，我应该更快地开始寻找新工作。我喜欢这篇发人深省的论文（“放弃重构”），因为它丰富了讨论：）

我同意，当有大量并行代码线时，您必须非常小心进行更大的重构，因为冲突会大大增加集成工作，甚至会导致在合并过程中引入回归错误

由于重构与功能分支的问题，有很多折衷之处。因此，我根据具体情况作出决定：

• 在特性分支上，我只在它们使我的特性更易于实现的情况下进行重构。我总是试着只关注功能。支线应尽可能与干线/干线不同
• 反过来说，我有时甚至会有重构分支，在那里我会进行更大的重构（还原多个步骤非常容易，我不会分散同事的注意力）。当然，我会告诉我的团队，我正在进行重构，并试图计划在清理开发周期中进行重构（如果您愿意，可以称之为sprint）
• 如果您提到的政治是一件大事，那么我将在内部封装重构工作，并将其添加到评估中。在我看来，中期客户在拥有更好的代码质量时会看到更快的进步。最有可能的是他们不理解重构（这很有意义，因为这超出了他们的范围…），所以我对他们隐瞒了这一点
• 我永远不会在一个以稳定性为目标的发布分支上进行重构。那里只允许修复bug

作为总结，我将根据代码行计划重构：

• 功能分支：只有较小的分支（如果它们“帮助”我的功能）
• 重构分支：对于更大的分支，重构目标并不完全清楚（我经常称之为“涂鸦重构”）
• 主干/主线：好的，但是我必须在功能分支上与开发人员沟通，以避免造成集成噩梦
• 发布分支：永远不会

---

特性分支无疑会使重构变得更加困难。它们还使得持续集成和部署等工作变得更加困难，因为需要构建一个测试的并行开发流的数量正在膨胀。您还回避了“持续集成”的核心原则——每个人都在使用相同的代码库，并且“持续”地将他们的更改与团队的其他更改集成在一起。通常，在使用功能分支时，功能分支不会持续构建或测试，因此“功能分支”代码第一次在生产构建/测试/部署过程中运行时，是在“完成”并合并到主干中时。这可能会在开发过程的后期和关键阶段引入大量问题
我持有有争议的观点，您应该（几乎）不惜一切代价避免特性分支。合并的成本非常高，而且（也许更重要的是）未能“持续集成”到共享代码库的机会成本更高

---

在您的场景中，您确定需要为每个客户端的功能单独设置一个功能分支吗？您是否可以在主干中开发这些功能，但在准备就绪之前将其禁用？。一般来说，我认为用这种方式开发“特性”更好——将它们签入到主干中，即使它们还没有准备好生产，但在它们准备好之前将它们放在应用程序之外。这种做法还鼓励您在精心设计的接口后面保持组件的良好特性和屏蔽。“功能分支”方法为您提供了在代码库中进行全面更改以实现新功能的借口。
重构和合并是重点关注的两个合并主题。事实上，有两个重要的方面需要关注：一个是处理（合并期间）已删除的文件。这里的好消息是，所有“新时代”的SCM都能让您正确地做到这一点（塑料、Git、Hg），而旧的SCM只能失败（SVN、Perforce和更旧的SCM）
另一部分是处理同一文件中的重构代码：你知道，你移动你的代码，其他开发人员并行地修改它。这是一个更难的问题，但我们也通过新的merge/diff工具集来关注它。查找和xmerge（交叉合并）。关于如何（与“无与伦比”相比）的良好讨论
而“目录合并”或结构合并问题是一个核心问题（whet