如何在分支上合并功能和错误修复

Question

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

MAIN
   |--- DEV
   |--- PROD

大多数开发都是在 DEV 分支中完成的。当代码准备好测试时，所有内容都合并到 MAIN 分支并发布到我们的测试环境。测试完成后，将完成与 PROD 的合并，并将所有内容发布到生产服务器。不时地对 MAIN 或 PROD 代码进行更改（主要是错误修复），但这是一个例外。

我被要求想出一个功能和错误修复合并的系统。这意味着 DEV 中的单独更改应该跨 MAIN 和 PROD 合并。在我们当前的设置中，这些信息会丢失：例如，功能 A、B 和 C 在 DEV 分支中实现。假设每个特性都有两个对应的变更集：A1、A2、B1、B2、C1、C2。使用我们当前的工作方式，所有内容都一次性合并到 MAIN 分支。因此，当我们想要“挑选”必须从 MAIN 到 PROD 的功能时，我们不能这样做，因为 MAIN 上只有一个变更集：合并签入。

你会如何解决这个问题？我需要对我的分支策略进行一些更改吗？

我正在使用 TFS 进行源代码控制。

Answer 1

因此，当我们想要“挑选”必须从 MAIN 到 PROD 的功能时，我们不能这样做，因为 MAIN 上只有一个变更集：合并签入。

如果愿意，您可以编写一个工具来整理合并历史记录，但真正的答案是不要这样做。当您挑选时，您将失去任何保证，即您在源分支中测试和稳定的代码将在目标分支中以相同的方式执行。有时这没问题，但在您的情况下，它违背了在未经测试的原始开发签入和实时 PROD 部署之间建立中间分支的全部目的。

正如my favorite branch/merge video 中所讨论的，您的指导原则应该是“向下合并，向上复制”。也就是说，每当需要解构和/或应用代码差异时，就让不稳定的分支受到影响。 （从其他集成的应用程序中挑选功能就是一个例子。）同时，向 Main 和 Prod 等稳定分支提升的代码应该始终是与您已经在源分支中努力稳定的内容相匹配的直接副本.听起来您目前正在遵循此策略；在面临挑剔的情况下保留它是我使用特性分支的第一大动机，甚至比将特性团队与彼此的损坏隔离开来更重要。

正如 Jim 所说，管理功能之间的依赖关系是一个问题。如果可以提前识别，通常的解决方案是创建具有共同依赖关系的特征共享的子分支。

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

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

Answer 2

我不认为这里有什么神奇的调味汁，你只需要找到一个系统，你可以在其中对你可能想要挑选的每个单元的 main 进行修订。

这可以通过单独合并每个修订来轻松完成，这很痛苦，但可以得到你想要的。

或者，您可以通过将每个功能一次合并到主要功能来提高粒度。这要求您按顺序处理功能，如果您自己一个人可能没问题，但如果有几个人会很痛苦，因为您必须经历一些人已经完成的代码冻结和其他人没有。

另一种可能会或可能不会更易于管理的工作方式是为每个功能创建一个 DEV 分支。从这个意义上说，与其拥有一个永远存在的 DEV 分支，不如拥有一个仅在功能完成之前存在的临时 DEV 分支的集合。

每个 DEV 分支的重新集成将在 main 中为您提供清晰的修订，可以挑选。

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

鉴于您的分支策略，我想您已经找到了这个，但如果没有，那么值得一读： http://branchingguidance.codeplex.com/wikipage?title=html&referringTitle=Home