我一直在重构我和其他人的代码。当我在一个分支而不是 Trunk 工作时，这有时会导致一些极其痛苦的合并，尤其是如果我不定期合并回 Trunk（分支的代码会慢慢从 Trunc 移开，当人们修改 Trunk 我必须手动弄清楚如何将其应用于分支）。
我知道的解决方案是
你做什么工作？
大规模的重构需要在开发时间线的正确时间进行。如果您在发布时进行大量重构，您最终会伤害自己，因为您会在应该最小化更改的时候引入痛苦的合并。您的重构越具有破坏性，它就应该在开发周期的早期发生（并且应该有更特殊的过程，例如在一段时间内尽可能停止对受影响文件的编辑）。
不断合并到主干和从主干合并通常是一种很好的做法。
在那种情况下，为什么要在分支机构工作？因为您有更多的控制权（例如，您可以停止合并到主干以稳定它以供发布，而无需停止签入您的开发分支）。因为您可以围绕合并到主干或从主干合并进行高级验证，而不会对开发分支的签入速度产生太大影响。
我选择 1，尽可能进行小改动并经常检查，否则合并会变得很痛苦。如果您需要同时处理其他事情，或者重构花费的时间比您最初想象的要多，拥有一个单独的分支可以使事情变得更容易。另一个好处是它使几个人更容易参与重构，并且您可以根据需要随时将内容签入分支。
对于发布之间的时间窗口至少为 2 个月的情况，我建议采用以下策略。
当你开始接近发布时，创建一个发布分支。发布分支应该被视为没有重构，我（几乎）是功能完整的分支。正是在这一点上，您应该开始集中精力稳定发布分支上的发布。根据需要将发布分支中的任何缺陷修复合并回主干。同时，主干被视为永久开放以进行重构。此外，如果可行，请尝试在接近主要版本时减少重构，并在紧随其后的几天内加速它。
如果您遵循持续发布策略（即每 1 到 2 周发布一次），则不应在单独的分支上分离重构和编码，除非您正在进行重大的手术增强。在这种手术增强情况下（每次间隔不少于 3 个月），每当您打算执行合并时，请提前从您的日程表中删除一个版本，使用其中一个周期进行版本合并和增加测试，保持您的手指交叉然后松开。
更改需要快速（因此您的更改不要太多）或本地更改（因此您只关心少数地方的更改）。
否则，合并可能与重构一样多。作为一种算法，当太多事务失败并且必须重新启动时，乐观锁定根本不起作用。
从根本上说，你不能允许一家公司的 20 名程序员每天都更改代码库中 50% 的方法的名称。就此而言，如果多人总是同时在同一个地方进行重构，那么无论如何他们只是在撤消彼此的工作。
If programmers are spending a lot of time manually supervising merges, then present to your managers an opportunity to increase productivity by changing the way tasks are defined and assigned.
Also, "refactor the whole system to use factories everywhere" is not a task. "Refactor this one interface and its implementations to use factories" is a task.
这是一个好的分布式 VCS 擅长的地方。但我猜你已经致力于 SVN。
就个人而言，我只是做重构然后尽快合并以避免冲突地狱。这不是最有效的方法，但最不容易出错。
我曾经有一个分支休眠了大约 3 周，因为该功能被“搁置”并且无法合并。我刚刚在一个新分支中重新启动了该功能，使用旧的作为某些部分的参考。
冒着明显的风险，我想说尽量避免完全分支。绝不能低估这导致的开销。即使你认为你不能再拖延了（在生产中发布一个系统，正在构建发布第二个，但也请求发布一个）仍然尝试找到另一种方法：你真的没有办法在没有分支的情况下隔离功能吗（例如，拆分一个“通用”项目和一些子项目）？真的没有办法整合所有代码（例如创建包含差异的策略类或创建开关以打开或关闭新功能）？
如果您绝对必须分支，我会选择选项 1。尝试合并尽可能小的更改并经常这样做。
尽早提交，经常提交。
或者在这种情况下......尽早合并，经常合并。
Continuous integration is the key... 1 small batch of changes at a time...