在Visual Studio中合并1年开发的策略

32

我有一个客户，坚持要求我们在2016年全年将我们的新开发与主要分支机构分开。他们还有3-4个其他团队以各种身份从事该应用程序的工作。已经进行了许多大的更改（切换依赖项注入的完成方式，使用ReSharper清理代码等）。现在，我不得不将main合并到我们的新dev分支中，以准备将我们的变更推向产业链。

在我最初的合并请求中，TFS报告了约6500个具有解决冲突的文件。其中一些将很容易，但其中一些将更加困难（特别是一些javascript，api控制器和支持这些控制器的服务）。

有什么办法可以使我更轻松？

为了澄清，在此过程中，我多次对此方法表示了很多关注。客户曾经并且知道与此有关的困难。因为他们选择短缺QA人员（一名测试人员需要4个开发人员，所以没有自动化测试，很少进行回归测试），所以他们坚持认为我们会把分支机构与主分支机构的更改隔离开来，以为这会减少对我们分支机构的需求。测试人员了解其他地方所做的更改。

这里最大的问题之一是对有角度版本和某些其他第三方软件的升级-不幸的是，直到所有组件放回原处，我们都没有想出一种构建此解决方案的好方法。

visual-studio merging

— 用户名
source

63

不。您有两个单独的分支机构，它们活跃地开发了一年。合并很烂。

— of 26

2

您的团队所做的更改程度如何？识别这些更改，然后将其手动重新应用于当前的主代码库，可能会更有效。

— kdgregory

2

是2015年还是2016年全年？如果将其2015年定为2年，这意味着它将翻倍。

— 大卫说莫妮卡（Monica）恢复职权

1

客户为什么要关心您为他们所做的工作是否在版本控制系统中的单独分支上？

— Ixrec

17

无论您做什么，都要确保按小时计费。

— 肖恩·麦克索明

37

有一种简单的方法可以使您的新开发与主分支分离，而不会使您陷入这种不幸的情况：对主干的任何更改都应该每天合并到您的dev分支中。（您的客户真的是目光短浅，以至于他没想到有一天您的分支机构需要重新合并到主线中吗？）

无论如何，最好的方法是恕我直言，尝试重做应该直接发生的事情：

识别语义的上主线的变化1天分支创建之后。尽可能将它们应用于当前代码库。如果是“本地更改”，则应该很简单，如果是“交叉重构”（例如重命名广泛使用的类），则应以语义等效的方式将其应用于当前代码库。希望在那一年，在“您的”分支上没有对代码库进行相互交叉的跨部门更改，否则这可能会成为真正的头脑挑逗
测试结果（我提到您需要为此任务提供良好的测试套件）吗？修复测试中发现的所有错误
现在，对第2天，然后第3天，依此类推，对主线上的更改重复此过程。

当团队严格遵守版本控制的经典规则（“仅提交可编译的，经过测试的状态”和“经常提早签入”）时，这可能会起作用。

经过365次重复（或250次重复，如果您幸运的话，您可以捆绑工作以进行周末更改），您将几乎完成（几乎是因为您需要添加在集成期间对主线进行的更改数量））。最后一步是将更新后的dev分支再次合并到主干中（这样您就不会丢失主干的历史记录）。这应该很容易，因为从技术上讲，它仅是受影响文件的替代品。

是的，我是认真的，可能没有捷径可走。可能会发现“每日份量”有时可能太小，但我不希望这样，我想每日份量可能会变得过大。我希望您的客户为此付出真正的代价，而且这对他来说太昂贵了，他将从失败中汲取教训。

我应该补充一点，您也可以在交换侧尝试一下-将分支中的更改重新整合到主要部分。如果在您的dev分支上所做的更改比主干上的更改少得多，或者大多数更改发生在当前不属于主干的新源文件中，则这可能会更简单。可以将其视为将功能从产品A（开发分支）“移植”到稍微不同的产品B（主干的当前状态）。但是，如果大多数跨领域重构都是在主线上完成的，并且它们会影响您的新代码（6500合并冲突似乎是对此的一些证据），那么我首先描述它的方式可能会更容易。

— 布朗博士
source

9

如果您在重新集成过程中继续在主干上进行开发，建议您先分支主干并从中进行开发。否则，您将有效地同时融合过去和未来。但我自然会就任何时空不连续性而向Doc Brown致意。

— –radarbob

1

@radarbob：您的建议只有在OP从开发人员集成到主干的情况下才有意义，但是当他决定从主干合并到开发人员时才有意义，正如我首先描述的那样。如果OP每天将更改从主干转移到他的dev分支（从过去365天的更改开始），则主干上的开发是否继续都没有关系。他只需要继续执行这种策略，直到他到达现在为止（假设他可以在一天之内整合并测试这3-4个团队的变化，而一天之内就可以完成）。

— 布朗

Quote：“我应该补充说，您也可以在交换侧尝试这种方法-将您日常分支中的更改重新集成到主线中。 ”我的幻想是在引信。我感觉到潜在的“谐波共振失真”级联与冲突的变化整合。

— –radarbob

这是很好的建议。请参阅编辑以在此处解决两件事。

— user258451

1

@ user258451：所以您有不同的QA团队负责树干和新的dev分支，谁不想互相交谈？伟大的斯科特：-（（

— 布朗

14

在合并的那个阶段，我要说的是，自动合并可能只会使流程复杂化。我在分支机构已经存在一年多的分支机构也遇到过类似的问题，而我最有效的方法是执行以下操作：

取得原始未合并状态的副本
在未合并和最新之间的差异
分解任何常见元素
- 例如，先更改所有函数名称，然后再更改参数等。
- 如果标准已更改，请忽略diff上的空白，否则您将浪费大量时间计算空格
首先关注核心功能

最终，编译器警告和diff将是您最好的朋友，继续使用未合并的diff来查看有什么不同，然后继续。您可能会使用各种工具来提供帮助，但是这取决于您自己选择哪种工具。

关键是要继续前进。

编辑：

提醒一下，这种方法将意味着版本控制历史记录将被“破坏”，因为您将丢失分支到分支合并以及未合并分支的历史记录的证据。

感谢'Jack Aidley'和'17 of 26'的评论

— 埃德里克·铁罗斯
source

1

这种方法的主要问题是，它将破坏版本控制系统中剩余的更改记录。

— 杰克·艾德利

本质上，通过在合并过程中第二次进行所有相同的更改，您仍将拥有更改的日志，它只是按合并中完成的顺序执行，而不是按开发期间进行的顺序进行。不理想，但总比没有好。另外，如果将其保留在版本控制中，则您仍将具有原始的未合并状态。

— Erdrik Ironrose'1

您将拥有更改的日志，但是您将没有历史证据表明更改已在分支之间合并。在TFS中，这将是一笔不小的交易，当您在分支之间合并时，它只为您提供未合并的变更集供您选择。

— 17年

@ 17of26我同意您可以恢复某些更改记录，但是26中的17是正确的，因为该记录将不完整或不正确。考虑到他们现在所处的糟糕局面，这种方法可能很容易使丢失记录成为可以接受的折衷。但是，我认为不管他们做出什么决定，识别它都是一个重要的缺点。

— 杰克·艾德利

1

@杰克·艾德利（Jack Aidley）我绝对同意这是个问题，因此我在回答中加了一点以反映出来。我希望可以吗？

— Erdrik Ironrose'1

8

几年前，我们有一个要求将分支机构分开的客户。我们做到了。

我们从来没有合并他们的分支。他们有自己独特的版本。我们向他们收取额外的更改费用，因为从本质上讲，我们有两个主干而不是1个主干和分支。

我们尝试合并回主干，但是两周后，我们决定放弃这项工作，因为这浪费了数小时的时间，没有任何实质性的收益。

因此，不要将其合并回去。继续根据需要将关键修补程序合并到该客户端分支，并且任何增强功能都将由该客户端专门承担。

— 乔恩·雷诺
source

仅当不同的开发线针对不同的客户时，此策略才可行。或者，如果涉及产品的用例允许以非集成方式并行使用两条不同的产品线。据我了解，OP描述了一种情况，其中新的开发线与使用主干的开发人员针对同一客户，并且不清楚同时使用两个产品线是否对他的情况有意义。

— 布朗

1

它不会很有趣，但是它将带来多大的痛苦取决于变化的性质以及变化的孤立程度。

我建议您在进行实际合并之前，尝试通过重构尽可能多地融合分支。

合并工具有点笨，因为它只能查看文本差异，而不能以任何方式理解代码。如果主分支更改了整个应用程序中使用的类的名称，而功能分支在某些新代码中使用了旧名称，则合并工具将无法理解该类名称也应在新代码中进行更改。但是，如果您在分支B中进行重构以像在分支A中那样重命名该类，则该类将在新旧代码中均起作用，并且合并将顺利进行。

其次，您应该检查开发分支中更改的本地化程度。如果功能分支中的更改仅局限于几个区域，则不必收敛未受影响的代码，您只需从主分支中复制和覆盖即可。

在两个分支上都进行了重要更改的代码区域中，您必须仔细检查代码并决定如何重写。

— 雅克
source