在我上一个工作场所中，我们的流程类似于“ git flow”，但是每个发布都有三个连续分支，而不是新的发布分支。
我们在Jenkins中实现了自动化，因此QA可以随时将整个Develop分支纳入Release，并开始测试可用的工作。
此工作的所有错误修复都在发行分支上完成，以将当前版本与开发中不需要的更改隔离开，然后在完成后合并回开发中。
这个想法是发布分支是一个完全隔离的构建，并且在任何时候，如果QA对发布分支的状态感到满意，他们可以按下Jenkins中的另一个按钮，然后自动将整个分支部署到生产和标签中它。
在我的新工作场所中，我目前是唯一从事我的特定项目的人，并且没有设置任何自动化或适当的git流程，因此我的计划是继续使用多年来使用的东西，但是其他项目正在使用标准的Git流程，我们一直在讨论这些差异。
在流程中-质量检查人员正在测试开发中的各个故障单，只有计划将实际发行版剪切时，才将其放到新的发行版分支上进行其他测试。从那时起，我们遵循相同的流程，即在发布分支上进行错误修复，然后将其合并到开发中。
我们一直在争论哪种方法更好，但是在使用我的流程多年之后，我无法在网上找到任何能说明我的优势或劣势的东西，这对我有帮助，我想知道是否存在我似乎不知道它存在问题，因为它似乎工作得很好？我不是在googlefu上失败还是感到找不到现有讨论？我还看到我的解决方式存在一些问题？
以我目前的方式
反之，
在测试构建时，开发已经向前发展。如果质量检查人员想将此构建部署到生产环境，则他们现在需要选择一个时间点并从中创建一个发布分支（由于不再是HEAD分支，因此可能容易出错）
我们的一个主要测试环境始终代表当前的开发代码库，因此当Develop中断时，网站就会中断并且无法进行测试。
在准备好剪切发行版时，连续发行分支方法相对于单个发行分支的gitflow是否缺少一些缺陷？
我觉得通过连续分支部署到生产环境更直接吗？即使他们立即停止对开发的测试并立即创建了唯一的发行分支，与标记了连续分支相比，这有什么好处？
注意-我不是最初在我上一个工作场所中进行此设置的人，并且将是我第一次进行自动化设置。与正常的git flow相比，在我的方法中会遇到自动化方面的问题吗？