分支策略-与gihub一起多次发布

Question

我正在从事这个项目，目前我们有以下三个固定分支

Develop - The code is deployed to development environment. It's a base branch for anyone who want to add new feature. 
Release - Deployed in QA environment, And QA can start testing on.  
Master -  Deployed to Production environment and available to clients. 

我们还有两个动态分支，Feature和Hotfix。

1. 任何人都想开始新的开发或错误修正，从feature分支派生新的develop，然后创建拉取请求。

2. 一旦完成开发，即从开发分支在开发环境中进行测试，然后为release branch

创建合并请求

3. 质量检查人员在测试环境中部署release分支，并在测试完成后开始测试。它被合并到母版，然后部署到生产中。

在大多数情况下，这一切都很好。但是，它存在以下问题

  

并非QA（发行分支）中的每个功能都经过测试，可以在发行结束时进行部署（合并到母版）。因此，我们不确定如何创建拉取请求，因为它将选择所有提交。

我认为Github releases可能是解决方案。我可以创建一个新版本，该版本可以使用所有功能进行部署，然后将这些版本与master分支合并。

但是，我不确定何时从发行版或从主服务器部署到生产环境？

Answer 1

您应该遵循标准的 Git Flow ：

在测试后，您无需将任何功能合并到release分支（来自develop），而是要使用“发行版”。这是您决定要发布的专用时间点。对计划在此版本中发布的功能进行评估和测试，并确认该版本。

您将要 tag your releases ，并选择包括与该发行版关联的任何资产，以供将来参考。如果是移动应用程序，那么这是放置.apk或.ipa的好地方。在制作了发布剪辑并标记了发布剪辑之后，您将想要将release分支发布到生产版本。将其部署到生产环境后，您将需要将release合并到master和develop中。

在这种方法下，每个 feature分支将以develop，然后是release（带有相应的tag），然后是{ {1}}。如果进行裁切时某个功能仍在进行中，则根本不会裁切！它将添加到 next 版本中。这将使它有足够的时间进行测试，然后才能到达master附近，更不用说release了。在这方面，master仅仅是您最后一个已知的“良好状态”的代表-在这一点上您很高兴向公众发布。

此外，请注意master和hotfixes是两回事，两者都不应该从bugfixes分支出来。应该对develop分支本身进行错误修复，并且应该从release创建hotfixes，然后将其合并回到master和master中。