我们有一个网络应用程序，我们有几个企业客户。我们最近决定将其作为 SaaS 应用程序提供，并遵循精益方法(与我们的企业产品并行)。这意味着我们正在进行可能无法投入生产的实验。
在我们精益化之前，我们对以下分支策略感到满意(我相信这是非常标准的):
- master - 始终稳定
- dev - 通常不稳定(功能分支切断了 dev 的新功能 进入下一个主要版本)
- major_release_x - 实时(在 dev merge 后切断 master 进入 master，这是修复错误并 merge 回 master 和 dev 的地方)
现在我们除了上述之外还有以下内容，但效果不是很好:
- lean_release_branch - 实时(切断 major_release_x 并包含 实验)
- experiment_x - 切断 major_release_x(这是我们破解的地方 功能组合在一起，然后将其 merge 到 lean_release_branch)
我们现在的情况是，我们需要按照精益方法的要求快速且频繁地发布，当我们获得对任意内容的可靠反馈时，我们需要将其生产化并尽快发布(离开 lean_release_branch) .
问题是我们无法创建 dev 的功能分支(因为它很可能不稳定)并且我们无法创建 lean_release_branch 有两个原因:
- 它已被实验代码污染，因此此更改/功能将无法返回master
- lean_release_branch 始终需要准备好发布，因此如果有关键问题需要，我们不能忙于对其进行测试和修复(在将更改/功能 merge 到其中之后)待修复并发布
有谁知道我们的设置有更好的策略吗？
最佳答案
除了 GitFlow nozari 提到的，还有 GitHub Flow .我工作的地方以此为基础(master 总是稳定的，在功能分支中开发，在 merge 前进行审查的 pull request)。我们的部署频率低于 GitHub，所以在 master 上我们使用 annotated tags跟踪发布和轻量级标签指向当前正在暂存/生产中的任何提交。这是由 capistrano-deploytags 管理的 ruby 。
除非我没有正确阅读您的问题，否则您可以使用此策略在所有这些分支中以较低的复杂性实现相同的目标。
关于新精简团队的 Git 分支策略，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17355062/