我目前正在为我的公司规划一个新的 Git 流程，其新想法是迁移到分叉和拉取请求以及添加一个暂存分支进行测试。
提议的分支规范
master（开发）- 包含来自开发人员功能/错误分支的前沿代码staging- 将自动部署到登台服务器的预生产代码库。由最终客户测试。production- 自动部署到生产服务器的经过全面测试的生产就绪代码。
所以最终它会是这样的：master-> staging->production
建议的设置流程
- 有一个官方
upstream仓库，每个开发人员都可以从中分叉他们自己的origin仓库 - 他们将其克隆到本地开发中
提议的开发流程
- 创建一个功能/错误分支
master - 咖啡代码魔术
- 完成后，他们
upstream/master从他们的分支创建一个拉取请求
在这种状态下，其他同事会查看该 PR 并提供建议或最终将其合并到upstream/master该功能最终应最终用于 QA 的地方，然后如果测试通过，则将其合并到生产中。
现在具有挑战性的部分是将测试的东西转移到staging最终客户进行测试以接受更改。
我考虑过的可能方法：
master将更改从to合并staging- 虽然这似乎是最简单的方法，但由于某种原因，它感觉最危险以及未完成的代码最终可能会进入暂存状态，这可能会导致最终客户的测试失败。master从到采摘樱桃staging- 比上述方法更安全，但在某些时候可能会变得乏味（？）将特性分支合并到
upstream/staging- 这很可能不起作用，因为特性分支在上游不可用upstream/staging直接发出拉取请求- 虽然这很方便，但缺少对master分支的使用（如果 PR 用于暂存，则必须从暂存中重新设置主节点。可能不是一个好主意？）。
在这种情况下，以一种干净的方式将特性从上游主节点转移到 QA 阶段的最佳或理想做法是什么？或者我只是在这一点上过于复杂了？