何时在 git-flow 开发中进行 QA

Question

我已经使用 Git-Flow 有一段时间了，我加入的新公司使用了 github-flow 的修改版本，其中：

1. 我们从主/功能分支中分离出来
2. 创建拉取请求
3. 合并到暂存分支
4. 将其部署到测试环境
5. 如果发现错误修复了我们一直在处理的同一分支并重新合并到暂存。(**1)
6. 如果在测试环境中一切看起来都不错，最后合并到 master

**1 我认为这就是我们遇到问题的地方。因为我们必须不断地从 master/feature 分支对我们的分支进行更改，重新合并到 staging 分支会导致不必要的错误。

这就是为什么我一直在网上寻找一个彻底的一步一步的 github-flow 指南并且没有太多运气。我试图更好地理解如何合并测试代码以自信地掌握。我知道推送到 master 的小改动会导致简单的修复，但毕竟你仍然需要在推送到 master 之前进行尽职调查。

我的目标不是了解事情的一般流程，而是详细了解出现问题时会发生什么等。

话虽如此，Github-Flow 在这种情况下是如何工作的：

1. 何时进行手动 QA 测试？是在 pull-request 合并到 master 之后还是之前？
2. 如果之前发生过手动 QAing，那么 QAs 如何同时测试多个拉取请求？他们是否需要为每个拉取请求提供一个单独的环境？
3. 当有缺陷的代码进入 master 阶段时，您是创建一个新分支来修复它还是回滚它？
4. 我见过开发人员使用带有 github-flow 的集成分支（例如“暂存”分支）在那里进行测试的团队。在实际将其合并到 master 之前，如何使用集成分支来检查事物？

编辑/注释

我很欣赏对不同分支策略的不同方法的评论，但我对 github-flow 遵循的流程更加好奇。