0

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

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

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

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

  1. 基于“staging”分支的功能分支，可以合并到 staging 中，然后在准备好时挑选出来掌握。
  2. 合并到 staging 以进行测试的功能分支，并在准备好时合并到 master。不确定是否最好将这些分支建立在 staging 或 master ...

无论哪种方式，我都遇到了合并冲突，实际上没有冲突，因为历史变得越来越混乱。这有点烦人。必须有更好的方法来做到这一点！

4

1 回答 1

1

Ugghhh 在任何情况下，您都冒着在 staging 中以一种在生产中不会发生的方式相互交互的风险，因为您没有将 staging 上的所有提交移到一起掌握，但是您一直在测试它们一起上演。

我认为 git 很难做到这一点，因为这不是一个好主意：-/ 使用功能翻转以便某些功能仅在暂存环境中处于活动状态但代码可以随时推送到生产环境怎么样？这将需要改变您的团队思考开发的方式——而不是更改现有代码，有时您必须在应用程序中添加一条并行路径，该路径使用最终将大量替换现有功能的新功能。

于 2013-10-01T22:00:16.793 回答