我一直在重构我和其他人的代码。
当我在分支而不是Trunk中工作时，有时会导致一些非常痛苦的合并，特别是如果我不定期合并回Trunk(分支上的代码缓慢地从Trunc移开，并且当人们修改Trunk I时)必须手动找出如何将其应用于分支)。

我知道的解决方案是

• 不断地与Trunk之间进行合并-减少了痛苦的合并，但是为什么要在分支中工作呢？
• 每当我们需要重构某些内容时，切换到Trunk，在那里进行重构并合并到分支中-我发现这不太实用，因为每次重构都需要切换环境，因此实际成本很高。

你做什么工作？

解决方案

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

大规模重构需要在开发时间表中的正确时间完成。如果我们在发布前进行大量重构，那么我们最终会受到伤害，因为在应将更改最小化的同时，我们将引入痛苦的合并。重构的破坏性越大，它应该在开发周期中就越早发生(并且应该有更特殊的过程，例如，在一段时间内尽可能停止对受影响文件的编辑)。

不断地与主干进行合并通常是一个好习惯。

在这种情况下，为什么要在分支机构中工作呢？因为我们拥有更多控制权(例如，我们可以停止合并到主干中以使其稳定发布，例如，而无需停止签入开发分支)。因为我们可以在与主干合并/从主干合并周围进行高级别的验证，而不会大大影响到开发分支的签入速度。

这是一个好的分布式VCS擅长的地方。但是我想我们已经致力于SVN。

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

我曾经有一个分支处于休眠状态约3周，因为该功能已"暂停"，无法合并。我只是在新分支中再次使用了该功能，并使用了旧的作为某些部分的参考。

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

当我们开始接近发行版时，请创建一个发行分支。 Release分支应在此处视为未重构，并且我(几乎)具有完整的分支。此时，我们应该开始将精力集中在稳定发行分支上的发行上。如有必要，将所有缺陷修复从版本分支合并回主干。同时，树干被视为永久开放以便进行重构。另外，如果可行，还应尝试减少重构，以使我们接近主要版本，并在紧随其后的几天内加快重构速度。

如果我们遵循连续发布策略(即，每1至2周发布一次)，则除非我们进行了重大的外科手术增强，否则不应在单独的分支上分别进行重构和编码。在此类外科手术增强情况下(每次间隔不少于3个月)，每当我们打算执行合并时，请提前从计划中删除一个版本，使用其中一个周期进行版本合并和增加测试，并保持手指交叉然后松开。

冒着明显的风险，我想尝试避免完全分支。造成这种情况的间接费用的金额不能被低估。即使我们认为无法忍受(发布生产中的一个系统，发布正在构建的两个版本，但更改请求以发布一个版本)仍然尝试寻找另一种方法：真的没有办法可以在没有分支的情况下隔离功能(例如，拆分一个"公共"项目和一些子项目)？真的没有办法在头上集成所有代码(例如，创建包含差异的Strategy类或者创建用于打开或者关闭新功能的开关)吗？

如果我们绝对必须分支，我会选择选项1. 尝试合并尽可能小的更改，并经常进行。

提早提交，经常提交。

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

更改需要或者很快(因此我们不需要太多更改)，或者需要本地(因此我们只关心少数地方的更改)。

否则，合并就可以像重构一样完成很多工作。作为一种算法，当太多事务失败而必须重新启动时，乐观锁定根本就不起作用。

从根本上讲，我们不能允许公司中的20位程序员每天都更改代码库中50％的方法的名称的情况。因此，如果多个人总是在同一时间在同一地点进行重构，那么他们反正只是在撤消彼此的工作。

如果程序员花大量时间手动监督合并，则可以通过更改定义和分配任务的方式，为经理提供提高生产率的机会。

同样，"重构整个系统以在任何地方使用工厂"也不是一件容易的事。 "重构此接口及其实现以使用工厂"是一项任务。

持续集成是关键...一次进行一小批更改...