我目前正在计划在我的公司中使用新的Git流程，并且它的新想法是迁移到分叉和拉取请求以及添加临时分支以进行测试。
建议的分支规范
master（开发） - 包含来自开发人员功能/错误分支的前沿代码staging - 将自动部署到登台服务器的预生产代码库。由最终客户测试。production - 经过全面测试的生产就绪代码，可自动部署到生产服务器。所以最终它会像：master - ＆gt; staging - ＆gt; production
建议的设置流程
upstream个回购邮件，每个开发人员都会自己发送origin个回购建议的开发流程
master upstream/master的分支在这种状态下，其他同事会查看该PR并提供任何建议或最终将其合并到upstream/master，该功能最终将最终用于QA的分段然后ff如果测试通过，则合并到生产中。
现在最具挑战性的部分是将测试的内容移至staging，以便最终客户接受测试以接受更改。
我想过的可能方法：
将更改从master合并到staging - 虽然这似乎是最简单的方法，但出于某种原因，感觉最危险的代码和未完成的代码都可以最终进行分期，最终客户的测试可能会失败。
从master到staging 采摘樱桃 - 比上述方法更安全但在某些时候可能变得单调乏味（？）
将功能分支合并到upstream/staging - 由于功能分支在上游无法使用，因此很可能无效
直接向upstream/staging提出拉取请求 - 虽然这很方便，但缺少master分支的使用（如果PR用于登台，请掌握必须从分期来重新定位。可能不是一个好主意吗？）。
在这种情况下，以干净的方式将功能从上游主站移动到QA的分段是什么样的最佳或理想的做法？或者我现在已经过度复杂了？