使用功能分支是否与重构兼容?

功能分支无疑会使重构更加困难。它们还使得持续集成和部署变得更加困难,因为需要构建一个测试的并行开发流的数量急剧增加。您还避免了“持续集成”的中心原则——每个人都在使用相同的代码库,并且“持续”地将他们的更改与团队的其他更改集成在一起。通常,在使用功能分支时,功能分支不会持续构建或测试,因此“功能分支”代码第一次在生产构建/测试/部署过程中运行是在“完成”并合并到主干中时。这会在开发过程的后期和关键阶段引入大量问题。

我认为有争议的观点是 . 合并的成本非常高,而且(也许更重要的是)未能“持续集成”到共享代码基中的机会成本更高。

在您的场景中,您确定需要为每个客户机的功能单独设置一个功能分支吗?你能在后备箱中开发这些功能,但在它们准备好之前将其禁用吗?。一般来说,我认为用这种方式开发“特性”更好——即使它们还没有准备好生产,也要将它们签入主干,但在它们准备好之前不要让它们出现在应用程序中。这一实践还鼓励您在设计良好的接口之后保持组件的良好因素和屏蔽。“feature branch”方法为您提供了在整个代码库中进行全面更改以实现新功能的借口。

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

由于重构与功能分支的问题,有很多折衷方案。因此,我逐案决定:

• 在功能分支上,我只在它们准备好让我的功能更易于实现时才进行重构。我总是只关注这个功能。分支应至少与干线/干线不同。
• 相反,我有时甚至有重构分支,在那里我做更大的重构(还原多个步骤非常容易,我不会分散我的主干同事的注意力)。当然,我会告诉我的团队,我正在进行重构,并试图在清理开发周期(如果您愿意,可以称之为sprint)期间进行重构。
• 我永远不会做的是重构一个发布分支,它的目标是稳定性。那里只允许修复错误。

总之,我会根据代码行来计划重构:

• 特性分支:只有较小的(如果它们“帮助”我的特性)
• 重构分支:对于更大的分支,重构目标并不完全清楚(我经常称之为“潦草重构”)
• 释放分支:从未

重构和合并是两个结合的主题 Plastic SCM 专注于。事实上,有两个重要的方面需要关注:一个是处理(合并期间)已经 moved or renamed on a branch . 好消息是,所有的“新时代”scm都能让你正确地做到这一点(塑料、Git、Hg),而旧的scm则只是失败(SVN、Perforce甚至更老的scm)。

另一部分是处理同一个文件中的重构代码:你知道,你移动你的代码,其他开发人员并行地修改它。这是一个比较困难的问题,但是我们也用新的merge/diff工具集来关注它。找到 xdiff info here here . 关于如何 find moved code here (与“无可比拟”相比)。

问题的一部分是,大多数合并工具都太愚蠢,无法理解任何重构。方法的简单重命名应该合并为方法的重命名,而不是编辑101行代码。因此,例如,应该自动处理对另一个分支中的方法的额外调用。

现在有一些更好的合并工具(例如 SemanticMerge )它基于语言解析,旨在处理已移动和修改的代码。JetBrains(重塑器的创建)刚刚发布了 blog 关于这个。

research 多年来,终于有一些产品上市了。