使用GitHub版本的分支策略

Question

我正在做这个项目，目前我们有三个固定的分支机构

• 开发-代码被部署到开发环境中。它是任何想要添加新功能的人的基本分支。
• 发布-部署在QA环境中，QA可以开始测试。
• 主-部署到生产环境，并提供给客户。

我们还有两个动态分支，功能和修补程序。

1. 任何人都希望启动新的开发或修复，从develop分支中分叉一个新的D11，然后创建一个拉请求。
2. 开发完成后，它将从develop分支在开发环境中进行测试，然后为release分支创建一个合并请求。
3. QA在测试环境上部署release分支，并开始测试，一旦测试完成，就合并到master，然后部署到生产中。

这一切都很好，对大部分的部分。但是，它有以下问题:并不是QA (发布分支)中的每个特性都经过测试，并准备在发行版的末尾进行部署(合并到主)。因此，我们不确定如何创建拉请求，因为它将选择所有提交。

我认为GitHub版本可能是解决这个问题的一种方法。我可以创建一个新的版本，其中的特性已经准备好进行部署，然后将这些版本与主分支合并。

然而，我不确定的是什么时候部署到生产，从版本还是从主人？

Answer 1

您需要确定在哪些条件下可以合并特性分支。一个典型的例子是，这个特性是完全实现的，并且通过CI进行自动化测试。

这意味着这取决于自动化测试，以确保该特性已经准备好由QA在发布分支上进行测试。这反过来意味着，除非QA能够在发布和部署之前对其进行测试，否则不应该合并该特性。

也就是说，您的过程包含这些阶段(我们在这里讨论的过程的一部分)：

1. 发展(特色支部)
2. CI测试(特征分支)
3. 合并特征->发布
4. QA测试(发布分支)
5. 合并发行版->母版

通过这样写出来，您可以看到每次测试发生在合并之前。如果将流程视为状态机，则分支是状态，合并是状态转换，测试检查是否可能发生状态转换。

确保相应地定义您的条件。