重构和并发开发分支

假设您的软件现有版本有几个维护分支.一些开发人员正在对维护分支进行直接更改,并定期合并到主干中.现在,在主干代码行中进行了广泛的重构,计划即将发布主要版本.但是这使得维护分支基本上与主干中的代码不兼容,因为它们可能依赖于不再存在的代码.

你如何在实践中处理这种情况？

我认为分支维护开发人员有责任将适当的更改合并到主干的当前状态.有几种可能性:

中继中的代码没有更改,补丁也没有冲突.

中继中的代码已更改且修补程序适用,但需要手动合并.

中继中的代码已完全更改,修补程序无法应用.开发人员必须评估主干中是否存在相同的缺陷,并在需要时应用等效的修补程序.

案例1和案例2是通常的维护发展路径.案例3是您正在考虑的情况,其中主干代码不能以任何形式接受维护补丁.如果开发人员无法自己确定主干中是否存在同样的问题,那么他应该在问题跟踪系统中输入问题.此问题将指导主干开发人员考虑维护分支中修补程序的原因以及是否仍存在相同的缺陷.为主干中的可能缺陷输入新问题应该是维护开发人员的最后手段.

让维护开发人员尝试将补丁应用于更新的主干的一个好处是增加他们对新代码库的熟悉程度.最终,他们将耗尽维护工作,并需要使用新的主干.至少具有基本的熟悉程度将是非常有益的.