带有复杂功能的git工作流程

Question

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

我已经对git工作流的主题进行了大量的搜索，但他们似乎都假设团队在一些开发分支上（可能是直接的，或者可能使用合并的功能分支）。当该分支中的所有内容都很好用时，它会合并到生产分支中（可能首先通过“发布”分支）并重复该过程。这是受欢迎的Successful Git Branching Model的工作方式。

问题是我们的“staging”分支（这是我们在上述Successful Git Branching Model中与“develop”分支最接近的分支）经常有代码处于完整性的不同阶段。因为我们无法在本地完全测试我们的代码，所以不完整或损坏的代码通常会在暂存分支中结束，因此实际上可以针对我们的应用程序在登台服务器上处理的大量数据进行测试。在将内容发布到生产环境之前，我们不能等待临时分支中的所有内容完全完成，测试和工作。

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

1. 基于“分段”分支的功能分支，可以合并到分段中，然后在准备好时将其挑选为主分区。
2. 功能分支，它们合并到分段进行测试，并在准备好时合并到主分区。不确定是否最好将这些分支机构设置为暂存或掌握......

无论哪种方式，我一直在进行合并冲突，因为历史变得非常棘手。那有点烦人。必须有更好的方法来做到这一点！

Answer 1

Ugghhh无论如何，你冒着提交的风险，以一种在生产中不会发生的方式相互交互，因为你没有将所有的提交提交到一起掌握，但你已经一起测试他们。

我认为git很难做到这一点，因为它不是一个好主意： - /如何使用功能翻转，以便某些功能仅在登台环境中有效，但代码可以随时推送到生产中？这需要改变团队对开发进行思考的方式 - 而不是更改现有代码，有时您必须通过应用程序添加并行路径，该应用程序将使用最终将取代现有功能的新功能。