所以我们使用Gitflow流程来获得安全可靠的CID（https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow）
但有些事情是错的。
假设我们在产品上有10个关键错误 - 它们必须尽快修复。所以10个错误被分配给10个开发者。 Dev 1创建一个修补程序0.0.1，提交修复程序，修复上传到staging env并交给QA进行验证。在那个时候dev 2想为他的bug创建修补程序0.0.2，但他不能，因为Gitflow禁止创建新的修补程序（如果已经存在）。所以他要么等待关闭hotfix / 0.0.1或者提交相同的修补程序。当然，正常的选择是提交到该修补程序/ 0.0.1，因为他的bug很关键，无法等待修复bug 1。
所有其他10个开发者都有10个关键错误。
QA验证错误1并确认部署。但是，无法关闭和部署修补程序，因为其他9个错误未经过测试或无法正常工作
因此，要关闭，该修补程序中的每个错误都必须正常工作并确认。在我们的情况下，这需要时间，很长一段时间 - 幸运的是1,2周 - 因为越来越多的东西需要尽快修复生产。所以开发人员越来越多地致力于这个分支，让第一个错误被搁置得更多。
所以最终，在所有这些错误得到修复并确认之后，是时候终止关闭修补程序并将这些关键错误部署到产品上......这需要相当长的时间延迟。但是还有另一个大问题 - 与开发分支的合并，其他开发人员的工作（如下一个版本的小错误修正）。一个可怕的，持续数小时的合并。
所以我们显然做错了什么 - 这可能是一个解决方案？为了我们的修补程序准时，并没有可怕的合并到开发。
我们想到的一个解决方案是在修补程序中限制它应该包含的错误数量 - 例如最多5个错误，其他错误必须等到修复它们。但是，这意味着只有lead-dev应该提交修补程序，因为他必须确保限制（否则很难控制）。但是这种方式仍然会被搁置，并且无法实现快速部署。
什么是正常程序？请分享您的想法。
如果你在合并上花了几个小时，那么你可能做错了。一种方法是让版本控制专家在一天内训练您的团队。与工资相比，这是一个相对较小的成本。我认为你可以找到一个非常优秀的人，每天500英镑（600美元），你可能只需要他们一两天。
我想知道你的测试（有QA团队）是否过于手动。错误修正是否可以伴随单元测试来证明它们是一种改进？如果是这样，开发人员应该能够将master合并到他们的bugfix分支中，为一些简单的QA检查启动一个新实例，获得QA来检查系统，让团队领导PR修复和单元测试，然后直接合并到掌握并重新部署。
此外，请确保您的部署完全自动化。每天做几次实时（小）发布是一个很好的目标。
上面的建议仍然存在，但既然你现在说这是一个旧项目：