0
我们有一个历史上遭受过大量分支机构的应用。并行工作和“突破性变化”的分支策略
这些已经得到批准，但现在已经出现了一种情况，即我们有两个开发流（理想情况下是一个开发流），其中一个流需要进行一些更改，其中实施它们会产生影响，作为单一故事的一部分（或可能是单一的冲刺）。
例如：需要大量查询逻辑更改的大量数据库模式更改。
这些更改不容易标记功能，因为它们系统地破坏现有功能，直到完成工作。理论上我们可以将系统重新置于“建筑”状态，但这会阻止客户使用现有的功能。
为了迎合这一点，我们建议为'突变'创建一个新的分支，以便其他开发流不被打破，并且可以间歇性地发布。
虽然我很讨厌创建新的分支机构，但目前看不到这样做的更好方法。
有没有推荐的做法，要么是分支策略管理，要么是体系结构保护，打破并行开发中的变化？
编辑：已经越过我心中唯一的另一件事是字面上“复制 - 粘贴”现有的功能（包括表/网页等），对其进行重命名，并在同一个分支上的工作，后面的功能旗。 由于多种原因，这显然很麻烦！
有没有人对他们过去如何应对这个问题有任何建议？
在理想的世界里，当然。导致我们遇到问题的原因在于，对于一个sprint而言，模式更改太大，因此需要对现有区域进行大量更改。 这些变化的冲击对DAL，BLL和UI同时具有重要意义。 主要问题是，在这种情况下，确保我们可以递增递送所需的努力量是巨大的，相比之下，允许“行李箱”在一段时间内变得不稳定。鉴于此，你会建议单独的分支可能是两个邪恶中的较小者？或者你会努力在单个分支上实现吗？ – dougajmcdonald 2015-01-21 17:32:22
我不能打这个电话。只有你的生意可以。在重构过程中，您仍然需要为客户提供价值吗？如果是这样，你必须去＃1。否则，你会得到两个不同的代码库 – 2015-01-22 05:30:29
你总是可以分解它。进行较小的更改。一次只能有一张桌子。 – 2015-01-22 05:31:34