我在一个小团队工作，开发一种处理大量昂贵数据的产品。由于与此数据相关的成本，因此无法在本地完全测试代码。相反，我们有一个客户端看到的生产服务器，以及一个用于测试的暂存服务器。同样，我们有一个与生产匹配的分支(我们使用"master"(，以及一个与暂存匹配的分支(称为"暂存"(。
我已经对 git 工作流的主题进行了大量搜索，但它们似乎都假设团队在某些开发分支上流失(可能是直接的，或者可能使用合并的功能分支(。当该分支中的所有内容都准备就绪时，它将被合并到生产分支中(可能首先通过"发布"分支(，然后重复该过程。这就是流行的成功 Git 分支模型的工作方式。
问题是我们的"暂存"分支(这是我们在上述成功 Git 分支模型中最接近"开发"分支的东西(经常具有处于不同完整性阶段的代码。由于我们无法在本地完全测试代码，因此不完整或损坏的代码通常最终会进入暂存分支，因此实际上可以根据我们的应用在暂存服务器上处理的大量数据对其进行测试。我们不能等到暂存分支中的所有内容都完全完成、测试和工作后，再将内容发布到生产环境。
那么处理这个问题的最佳方法是什么？到目前为止，我已经尝试了：
- 基于"暂存"分支的功能分支，可以合并到暂存中，然后在准备就绪时精心挑选以掌握。
- 功能分支合并到暂存进行测试，并在准备就绪时合并到主节点。不确定最好将这些分支建立在暂存还是主...
无论哪种方式，我一直在遇到合并冲突，因为历史变得很糟糕。这有点烦人。一定有更好的方法可以做到这一点！
呃，无论如何，您都冒着在暂存时提交的风险，这种方式在
生产中不会发生，因为您不会将所有暂存提交移动到一起掌握，但您一直在一起暂存时测试它们。
我认为 git 让这变得困难，因为这不是一个好主意：-/使用功能翻转，以便某些功能仅在暂存环境中处于活动状态，但可以随时将代码推送到生产环境，该怎么办？这将需要改变你的团队对开发的看法——有时你必须通过应用程序添加一条并行路径，而不是改变现有的代码，该路径使用最终将大量替换现有函数的新功能。