如何使用TFS进行功能分支策略

Question

我正在尝试为我们公司提出一个新的分支策略，我想知道是否有任何边缘案例我没有考虑到我的想法。

首先，这是我们目前的分支策略：

每个团队都有自己的开发分支，团队1和团队2非常小，因此他们没有像团队3那样的单独QA环境。每个团队将他们的更改合并到Main并返回到他们的Development分支。

目前我正在使用第3组，而我想要替换的策略特别是在第3组的部分。我们正在挑选从Main到INT到QA到Dev的变更集，然后再一次备份。没有完整的分支合并，我开始相信我们所做的每一次合并都是毫无根据的合并，因为我们只是挑选。

我正在尝试做的是不再需要不断挑选变更集并重新合并整个分支机构，这就是我想出的：

对于长时间运行的功能，我们将创建功能分支，dev将主要用于在下一版本中用于生产的错误和用户故事。

在QA分支中没有进行任何开发，我们只会在准备好测试时将DEV的更改合并到DEV。

一旦所有测试都通过，我们将合并到Main，并为main创建一个版本分支，用于下一个版本。版本分支将允许我们有一个干净的分支来执行修补程序，因为我们有多个团队合并到main。

希望尽可能地利用功能分支和搁置集来消除对樱桃变换集的需求，并希望减少我们目前拥有的疯狂合并冲突量。

这看起来像是一个合理的策略吗？

Answer 1

每个环境的分支通常是不好的做法。您应该构建一次，然后通过环境管道部署该构建。每次合并代码并创建新版本时，您都会有效地抛弃您已经完成的所有测试并从头开始。

隔离功能切换后正在开发的功能。在考虑完每个功能后，将其合并到Main，这将启动您的QA周期。然后其他团队应该从Main合并回他们的功能分支，以便继续针对相同的代码库进行开发。

如果某个功能被视为未准备好生产，请通过功能切换将其停用，然后您仍然可以发布 准备好的功能。您将功能集成在一起后，某人错过了错误的可能性就越高。具有集成但禁用的功能可帮助您证明，至少禁用的功能不会破坏其他任何功能。它可能无法正常工作，但至少它没有破坏应用程序。

随着这个模型变得更加自然，你可以完全放弃功能分支，直接从主干开始工作。

More reading on feature toggles.