在我工作的地方，我们最终将代码转移到了 Azure DevOps，并且我们正在尝试找到一种方法来获得对开发人员和测试人员都尽可能有效的顺利流程。
我们的计划是建立一个名为 main 的分支，我们将从中进行发布。禁止对 main 进行任意提交，以保持其历史相对紧凑。拉取请求将成为我们在生成新版本之前将错误修复合并到主版本中的机制。
错误修复将在主分支的（临时）分支中完成，开发人员将在其中修复缺陷。我们的想法是让我们的测试/QA 同事在这些错误修复分支中进行测试，并且只有当修复正确时才会将它们拉入主分支。
但问题是：在 QA 测试一个分支（主干之外）之后，他们不太愿意在拉取请求通过后重复测试，这也许是可以理解的。但是，在经过测试之前，我们有点不愿意接受拉取请求，以避免出现测试失败并且最终针对单个缺陷进行多次提交的情况。先有鸡还是先有蛋！
我们没有良好的自动化测试覆盖率，因此绝对依赖 QA 为任何候选版本开“绿灯”。测试主要是人类的努力，因此需要时间和勤奋才能正确完成。
其他人有遇到此问题或类似工作流程问题的经验吗？有没有一个适合所有人的好解决方案？相信合并“做正确的事”是天真的吗？
感谢所有建议。我们边走边学！
您可以在主分支和临时错误修复分支之间引入 QA 分支。
您已经拥有一个严格用于发布的主分支，并为开发人员使用临时错误修复分支。
当你的测试/QA同事对这些bugfix分支进行测试并感到满意时，他们可以先将它们合并到QA分支中，而不是直接将bugfix分支合并到主分支中。
当您计划发布新版本时，QA 分支可能已经包含许多修复程序。他们可以测试 QA 分支，一旦确认 QA 分支没问题，他们就可以将 QA 分支合并到主分支中。现在你可以释放它了。
这样，您的测试/QA 同事就不必每次合并后都重新测试，并且主分支保持干净和稳定。