如何通过分支合并功能和bug修复

Question

简单地说，我有以下分支机构设置：

MAIN 
    |--- DEV 
    |--- PROD 

大部分发展在Dev分支完成。当代码准备好测试时，所有东西都被合并到MAIN分支并发布到我们的测试环境中。当测试完成后，合并到PROD就完成了，所有内容都发布到生产服务器上。时不时地更改（主要是错误修正）在MAIN或PROD代码上，但这是一个例外。

我被要求考虑一个功能和错误修复合并的系统。这意味着DEV中的单独更改应该在MAIN和PROD之间进行合并。使用我们当前的设置，此信息将丢失：例如，在DEV分支中实现了功能A，B和C.假设每个特征都有两个对应的变更集：A1，A2，B1，B2，C1，C2。用我们目前的工作方式，一切都合并到MAIN分支。所以当我们想要从主要到PROD的“樱桃挑选”功能时，我们不能这样做，因为MAIN上只有一个变更集合：签入合并。

你会如何解决这个问题？我需要改变我的分支策略吗？

我使用TFS进行源代码管理。

Answer 1

所以，当我们想“樱挑”的功能，能去从MAIN到PROD，我们不能这样做，因为MAIN上只有一个变更集合：签入合并。

你可以写通过合并历史拼凑一个工具，如果你喜欢，但真正的答案是不这样做。当你选择樱桃时，你将失去任何保证，你在源分支中测试和稳定的代码将在目标分支中执行相同的操作。有时候没关系，但在您的情况下，它会打破在原始未经测试的开发人员签入和现场PROD部署之间设置中间分支的整个目的。

正如my favorite branch/merge video所述，您的指导原则应该是“合并，复制”。也就是说，只要需要解构和/或应用代码差异，就让不稳定的分支接受命中。 （另外一个集成应用程序的Cherry采摘功能就是一个例子。）与此同时，向主稳定分支（如Main & Prod）推广的代码应该始终是一个直接副本，与您已经在源代码分支中稳扎稳打的工作相匹配。听起来你现在正在遵循这个策略;将它保存在樱桃采摘面前将成为我使用特征分支的首要动机，甚至比绝缘特征团队更容易使用特征分支。如Jim所说，管理功能之间的依赖关系是一个问题。如果您可以提前识别它们，那么通常的解决方案是使具有共同依赖项的要素共享的子分支。

Feature1 
    \ 
    LibA--- 
    / \ 
Feature2 \ 
      DEV -- MAIN -- PROD 
Feature3 /
    \ /
    LibB--- 
    /
Feature4  

软件并不总是按计划进行，当然。如果需要共享代码的分支位于树的相对两侧（例如，如果Feature1依赖LibA 和 LibB，但由于结构或技术原因，Feature2不适合成为B的一部分，则这完全不起作用）。

Answer 2

我不认为这里有任何魔术酱，你只需找到一个系统，你可以选择你喜欢的每个单位的主版本。

这可以通过单独合并每个修订而轻松地完成，这是一种痛苦，但会让你得到你想要的。

或者，您可以通过将每个特征合并到主特征中来提高粒度。这就要求你按顺序开发一些功能，如果你是自己开发的，这些功能可能会好起来，但是如果你们中有几个人会感到痛苦，因为你必须通过代码冻结来完成一些人的工作，其他人没有。

另一种工作方式，你可能会或可能找不到更容易管理的是每个功能都有一个DEV分支。在这个意义上，不是有一个永远存在的DEV分支，而是有一个临时DEV分支的集合，这些分支只有在该特征完成时才存在。

每个DEV分支的重新集成将给你一个明确的修改主要可以挑选樱桃。

您可以获得开发分支之间的依赖关系。说分支devA需要分支devB的一些实现，你必须将devB的必要部分合并到main中，然后将它们合并到devA中。但是，devA不应该需要devB的未完成工作，所以无论如何你都应该（理论上）能够愉快地指出那些部分。当然，由于您正在选择PROD，因此这些部分集成不必公布。

鉴于你的分支策略，我想你已经发现了这一点，但如果没有，这是值得一读： http://branchingguidance.codeplex.com/wikipage?title=html&referringTitle=Home