当前使用Dev管道（Jenkins）部署和测试应用程序
源代码位于Gitflow workflow之后的GitLab的develop分支中
在创建develop分支之前，QA管道将在标记release分支中的特定提交之后触发构建，测试和部署，如下所示：
按照Git流程，理想情况下，质量检查管线应在工件（${release_num}-${JenkinsBuildNum}-SNAPSHOT.jar）上触发，而不是在develop分支中的git commit上触发。
将应用移至质量检查空间进行质量检查小组的测试后，
1）开发团队是否不应该在develop分支中创建任何新的提交？除非质量检查小组发现任何错误
2）QA管道生成的工件的命名约定应该是什么？开发管道生成名称为${release_num}-${JenkinsBuildNum}-SNAPSHOT.jar的工件
最佳答案
我不确定我是否正确理解了您的问题的描述，所以我尝试重新表述一下：
您正在使用某种持续集成和部署服务器。
您的源代码在GitLab上。
在您的develop分支上标记一个提交将触发QA管道/构建，该管道将从该提交构建您的应用程序并将其部署到QA空间，以便测试人员可以安装和测试它。
现在，您的问题似乎是：
开发团队是否必须等待（“代码冻结”）提交到develop分支，直到测试人员完成测试？
如果您问我上面所描述的内容，我的回答将是以下内容：
将来尝试将git flow工作流程用作git分支模型。
对于当前的问题，只需根据在develop分支上标记的提交创建另一个分支，并将该分支命名为release。
现在，开发人员可以继续正常处理新功能，并将更改提交到您的develop分支。
如果测试人员发现任何需要修复的错误，则可以在release分支上执行此操作。修复所有问题后，您可以从发行分支构建经过测试的应用程序版本。
完成后，不要忘记将您在release分支上所做的错误修复合并回develop分支。
在澄清问题后进行编辑：
正如我所看到的：如果正确应用Gitflow，它实际上应该可以完全解决您在问题1中提出的问题：
您的日常开发人员工作所添加到的分支是develop。当您实现所需的所有功能并认为已准备好发布某些内容（从开发人员的角度来看）时，您可以创建release分支以将当前版本（您的发布候选版本）保存在某个地方，并让测试人员使用验证此版本。作为开发人员，您可以继续研究下一个功能，并继续将更改提交到develop分支。
当测试人员发现错误时，可以在release分支上修复该错误。修复所有问题后，您可以从release分支创建应用程序版本并将其发布给客户。当它实际发布时，您可以将release分支推送到master分支，还可以将release分支上的更改合并回develop。
因此，据我所知，release分支的存在完全是为了避免您的问题1）。
您的流程很可能以这种方式工作，但是为什么在测试人员进行测试之后创建release分支呢？
关于testing - 质量检查阶段的新提交，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/55356355/