复杂的git工作流

我在一个小团队中工作，开发一种处理大量昂贵数据的产品。由于与此数据相关的成本，不可能在本地完全测试代码。相反，我们有一个客户机可以看到的生产服务器和一个用于测试的暂存服务器。同样，我们有一个与生产相匹配的分支（我们使用的是“master”），还有一个与staging相匹配的分支（称为“staging”）

我在git工作流的主题上做了大量的搜索，但是他们似乎都认为团队在某个开发分支上进行了大量的工作（可能是直接的，也可能是使用合并到中的功能分支）。当该分支中的所有内容都可以运行时，它就会合并到生产分支中（可能首先通过“发布”分支），并且过程会重复。这就是流行的作品

问题是我们的“staging”分支（这是我们在前面提到的成功的Git分支模型中与“development”分支最接近的分支）经常有处于不同完整性阶段的代码。由于我们无法在本地完全测试代码，不完整或损坏的代码通常会在暂存分支中结束，因此实际上可以针对我们的应用程序在暂存服务器上处理的大量数据进行测试。我们不能等到staging分支中的每件事情都完成、测试和工作，然后再将它们发布到生产环境中

那么最好的处理方法是什么？到目前为止，我已经尝试过：

基于“staging”分支的功能分支可以合并到staging中，然后在准备就绪时将其挑选给master

功能分支合并到用于测试的暂存中，并在准备就绪时合并到主分支中。不确定这些分支是基于staging还是master

---

无论哪种方式，我都会遇到合并冲突，但实际上没有冲突，因为历史变得越来越混乱。那有点烦人。一定有更好的办法

Ugghhh在任何情况下，您都有在登台时提交的风险，因为您没有将登台时的所有提交一起移动到master，而是在登台时一起测试它们，因此在生产中不会发生这种情况

我认为git很难做到这一点，因为这不是一个好主意：-/如何使用特性翻转，以便某些功能只在登台环境中处于活动状态，但代码可以随时推送到生产环境中？这需要改变你的团队进行开发的思维方式，而不是改变现有的代码，有时你需要在应用程序中添加一条并行路径，使用新的功能，最终取代现有的功能