tfs - 如何使用 TFS 执行功能分支策略

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

首先，这是我们当前的分支策略:

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

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

我想做的是消除不断挑选变更集并返回合并整个分支的需要，这是我想出的:

对于长期运行的功能，我们将创建功能分支，开发人员将主要用于处理错误和用户故事，这些将在下一个版本中投入生产。

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

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

我们希望尽可能多地利用特性分支和搁置集来消除挑选变更集的需要，并希望减少我们目前遇到的大量合并冲突。

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

最佳答案

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

隔离功能切换后面正在开发的功能。由于每个功能都被视为“完成”，因此将其合并到 Main 中，这将启动您的 QA 周期。然后其他团队应该从 Main 合并回他们的功能分支，以便继续针对相同的代码库进行开发。

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

随着这种模式对团队来说变得更加自然，您可以完全放弃功能分支，直接在主干上工作。