Tfs 如何通过分支合并功能和错误修复

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

MAIN
   |--- DEV
   |--- PROD

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

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

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

---

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

我认为这里没有什么神奇的调料，你只需要找到一个系统，在这个系统中，你可以为你可能想要挑选的每个单元修改main

这可以通过单独合并每个修订版来完成，这是一个痛苦的过程，但却可以满足您的需求

或者，您可以通过一次将每个功能合并到主功能中来提高粒度。这就要求你按顺序处理特性，如果你独自一人，这可能没问题，但如果有几个人，这将是一件痛苦的事情，因为你必须经历代码冻结，有些人已经完成了，而有些人还没有完成

另一种工作方式，您可能会觉得更易于管理，也可能不会觉得更易于管理，那就是为每个特性设置一个DEV分支。从这个意义上说，与其拥有一个永远存在的开发分支，不如拥有一个短暂的开发分支集合，这些分支只在功能完成之前存在

每个开发分支的重新整合将为您提供一个清晰的主要修订版，您可以选择

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

考虑到您的分支策略，我想您已经找到了这一点，但如果没有，则值得一读：

因此，当我们想要“樱桃选择”必须从一个主功能转到另一个产品的功能时，我们不能这样做，因为在主功能上只有一个变更集：合并的签入

如果愿意，您可以编写一个工具来分割合并历史，但真正的答案是不要这样做。当您选择cherry pick时，您将无法保证您在源分支中测试和稳定的代码将在目标分支中以相同的方式执行。有时这没关系，但在您的情况下，它破坏了在未经测试的原始开发人员签入和live PROD部署之间建立中间分支的全部目的

正如中所讨论的，您的指导原则应该是“向下合并，向上复制”。也就是说，每当需要解构和/或应用代码差异时，让不稳定的分支承担责任。（Cherry从其他集成应用程序中挑选功能就是一个例子。）同时，向稳定分支（如Main&Prod）升级的代码应该始终是一个直接副本，与您在源分支中已经努力稳定的代码相匹配。听起来你现在正在遵循这个策略；我使用特性分支的第一个动机是在面临樱桃选择的情况下保留它，甚至比使特性团队不受彼此破坏更重要

正如Jim提到的，管理功能之间的依赖关系是一个问题。如果您可以提前识别它们，通常的解决方案是创建由具有公共依赖关系的功能共享的分支

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

---

当然，软件并非总是按计划运行。如果需要共享代码的分支位于树的两侧（例如，如果Feature1依赖于LibA和LibB，但Feature2由于结构或技术原因无法成为B的一部分），那么这根本不起作用。

是的，我已经读过了，感谢链接。我认为我的问题的部分解决方案是开始使用特性分支。谢谢你的回答。有人有新的视频链接吗？我发现这一个可能是也可能不是同一个视频，但肯定很有趣