如何在一个分支中重构而不会失去理智？

Question

我一直在重构我和其他人的代码 。 当我在分支而不是Trunk中工作时，这有时会导致一些非常痛苦的合并，特别是如果我不定期合并回Trunk（分支处的代码慢慢地从Trunc转移，当人们修改Trunk I时）必须手动弄清楚如何将其应用于分支。）

我知道的解决方案是

1. 不断与Trunk合并 - 减少痛苦的合并，但那么为什么要在分支机构工作呢？
2. 每当你需要重构一些东西时，切换到Trunk，在那里进行重构并合并到你的分支 - 我觉得这不太实用，因为每次重构的切换环境的实际成本都很高。

你做什么？

Answer 1

需要在开发时间表中的适当时间进行大规模重构。如果你在释放附近做了大量的重构，你最终会伤到自己，因为你会在最小化变化的时候引入痛苦的合并。您的重构将在开发周期的早期发生的破坏性越大（并且应该对其进行更特殊的处理，例如在一段时间内尽可能多地停止对受影响文件的编辑）。

与行李箱不断合并通常是很好的做法。

在这种情况下，为什么要在分支机构工作？因为你有更多的控制权（你可以停止合并到trunk中以稳定它以便释放，例如，不必停止签入你的开发分支）。因为您可以围绕合并到/从主干进行高级别的验证，而不会影响开发分支的签入速度。

Answer 2

我选择1，在可能的情况下进行小的更改并经常检查，否则合并会变得很痛苦。如果您需要同时处理其他事情或者重构需要比您原先想象的更多时间，那么拥有一个单独的分支可以使事情变得更容易。另一个好处是它可以让几个人更容易参与重新分解，你可以随时检查分支机构的内容。

Answer 3

对于版本之间的时间窗口至少为2个月的情况，我建议采用以下策略。

当您开始接近某个版本时，请创建一个版本分支。发布分支应视为此处不进行重构和我（几乎）功能完整的分支。在这一点上，您应该开始集中精力稳定发布分支上的发行版。根据需要将任何缺陷修复程序从发布分支合并到主干上。同时，主干被视为永久打开以进行重构。此外，如果可行，请尝试减少重构，因为您接近主要版本并在紧接其后的几天内加速重构。

如果您遵循连续发布策略（即每1至2周发布一次），则不应将重构和编码分开在不同的分支上，除非您正在进行重大的手术增强。在这种手术增强情况下（每个应间隔不少于3个月），每当您打算执行合并时，请提前从您的日程表中删除一个版本，使用其中一个周期进行发布合并并增加测试，保持手指交叉然后释放。

Answer 4

更改必须是快速（因此不要在您之下进行太多更改）或本地（因此您只关心少数地方的更改）。

否则合并可以和重构一样多。作为一种算法，当过多的事务失败并且必须重新启动时，乐观锁定根本不起作用。

从根本上说，你不能允许公司中的20名程序员每天都更改代码库中50％方法的名称。就此而言，如果多个人总是同时在同一个地方进行重构，那么无论如何他们只是在解开彼此的工作。

如果程序员花费大量时间手动监督合并，那么通过更改定义和分配任务的方式，向您的经理提供提高工作效率的机会。

此外，“重构整个系统到处使用工厂”不是一项任务。 “重构这个接口及其实现以使用工厂”是一项任务。

Answer 5

这是一个优秀的分布式VCS擅长的地方。但我猜你已经致力于SVN了。

就个人而言，我只是做重构然后尽快合并以避免冲突地狱。它不是最有效的方法，但最不容易出错。

我曾经有一个分支处于休眠状态大约3周，因为该功能被“搁置”并且无法合并。我刚刚在一个新分支中重新启动了该功能，使用旧的作为某些部分的参考。

Answer 6

冒着明显的风险，我会说尽量避免分支。不应低估这导致的开销量。即使你认为你不能再拖延了（在生产中释放一个系统，释放两个正在构建但也改变发布一个的请求）仍然试图找到另一种方式：你是否真的没有办法在没有分支的情况下隔离功能（例如，拆分“共同”项目和一些子项目）？您是否真的无法将所有代码集成到头上（例如，创建包含差异的策略类或创建开关以打开或关闭新功能）？

如果你绝对需要分支，我会选择1.尝试合并尽可能小的变化并经常进行。

Answer 7

提早提交，经常提交。

或者在这种情况下......经常合并，经常合并。

Answer 8

持续集成是关键......一次只做一小批改变......