我正在尝试为我们公司提出一个新的分支策略，我想知道是否有任何边缘情况我没有考虑到我提出的问题 .
首先，这是我们目前的分支策略：
每个团队都有自己的开发分支，团队1和团队2非常小，因此他们没有像团队3那样的单独QA环境 . 每个团队将他们的更改合并到Main并返回到他们的Development分支 .
目前我在第3组，我想要替换的战略是在第3组的部分 . 我们正在挑选从Main到INT到QA到Dev的变更集，然后再一次备份 . 没有完整的分支合并，我开始相信我们所做的每一次合并都是毫无根据的合并，因为我们只是挑选 .
我正在尝试做的是消除不断挑选变更集并回到合并整个分支的需要，这就是我想出的：
对于长时间运行的功能，我们将创建功能分支，dev将主要用于在下一版本中用于 生产环境 的错误和用户故事 .
在QA分支中没有进行任何开发，我们只会在准备好进行测试时将更改合并到DEV的QA .
一旦所有测试都通过，我们将合并到Main并为main创建一个版本分支，用于下一个版本 . 版本分支将允许我们有一个干净的分支来执行修补程序，因为我们有多个团队合并到main .
希望尽可能地利用特征分支和搁置集来消除对樱桃变换集的需求，并希望减少我们当前拥有的疯狂合并冲突量 .
这看起来像是一个合理的策略吗？
1 回答
按环境分支通常是不好的做法 . 您应该构建一次，然后通过环境管道部署该构建 . 每次合并代码并创建新构建时，您都会有效地抛弃所有已完成的测试并从头开始 .
隔离功能切换后正在开发的功能 . 由于每个功能都被视为“已完成”，因此将其合并到Main，这将启动您的QA周期 . 然后其他团队应该从Main合并回他们的功能分支，以便继续针对相同的代码库进行开发 .
如果某个功能被视为未准备好 生产环境 ，请通过功能切换将其禁用，然后您仍然可以释放已准备好的功能 . 您将功能集成在一起后，某人错过了错误的可能性就越高 . 具有集成但禁用的功能可帮助您证明，至少，禁用的功能不会破坏应用程序 .
随着这个模型变得更加自然，你可以完全放弃功能分支，直接从主干开始工作 .
More reading on feature toggles.