听起来，你已经非常接近选择Git Flow了。实际上，如果我没记错的话，这已经是你所描述的策略的基础。这很棒。
我听到你的主要关注点是，你想要一个非发布的“develop”分支，有点像一个“尝试一下，可能不会编译”的环境/分支。Git flow确实倾向于生产“流”。也就是说，一旦从功能分支合并到develop分支中的任何内容，它就几乎预定为下一个（非紧急）发布。
Git flow对如何处理此问题的建议是，在一个任务/功能被合并到develop之前，不要合并它，直到它准备好以便在下一个分期/产品发布时进行一些修复。在git flow中，您将始终使用非快进式合并(git merge --no-ff FEATURE_BRANCH_NAME)，以便如果您接近分期/产品发布，并且此功能无法准备好，您可以反向合并(单个)合并提交，从而将其从develop或release-branch中删除。
我猜这方面需要更长时间的讨论，但我只是想提出两种可能满足你想法的方式：
1) 有两个develop分支: 一个用于开发，develop分支，它将在一些QA或其他之后很快安排到分期和产品发布。还有一个用于实验性的东西，将进入dev/test环境(例如通过持续部署)。让我们称之为long-term-develop（这是一个糟糕且太长的名字，所以请取一个更好的名字，否则你的团队会讨厌你 :)）。
想法:
- develop分支应经常合并到long-term-develop分支中，以始终保持其更新。
- 您可能需要两个开发环境来测试，每个分支一个。
危险: 从 long-term-develop 创建的分支（可能是错误的）合并到 develop 可能会将更多未准备好的内容拖入到 develop 分支中。解决方案可能是 1) 将 feature-branch 合并为非快进方式到 long-term-develop 和 2) 将此提交以 cherry-pick 合并到 develop 中。但这是容易出错和有点复杂的，一个错误的合并可能会破坏整个 develop 分支，污染其中未准备好的内容。
2) 只有一个 develop 分支（如您所建议的），并从 master 创建 release-branches
这可能是迄今为止最简单的方法。每个开发人员需要付出一些额外的努力，但错误率较低。
步骤如下：
- 在每个 sprint/development-cycle 的开始，release-manager 基于 master 创建下一个 release-branch。例如 release-sprint-42，当创建时，它等同于 master 分支。
- 开发人员使用基于 develop 的 feature-branches。像您当前建议的那样，一旦准备好进行测试等，他们将 feature-branch 合并到 develop 中。
- 如果特性是“正确”的且可工作的，则从将 feature-branch 合并到 develop 时创建的合并提交使用
-m 选项在 release-sprint-42 中进行 cherry-pick，例如 git cherry-pick -m 1 COMMIT_HASH。在这里，了解您选择的父级非常重要（在我的示例中为父级 1）。开发人员应阅读并理解：http://git-scm.com/docs/git-cherry-pick。
想法：
- 存在一个问题，即在develop分支中工作正常的功能，在release-sprint-42分支中可能由于缺少依赖而无法使用。因此，谢天谢地，我们有了分阶段环境和内部截止日期 :)
- 挑选代码并不是最容易的事情。但绝对是尝试避免将不需要的代码带入错误分支合并的最佳方法。
总结
哪种选择对您来说最好，取决于您的开发方式。如果您有2个轨道，例如“日常支持内容”和“计划在今年12月发布的我的大功能”，则可以选择2个分支。如果长期开发不仅是1件事，而是多个事情且正在进行（即通常有很多任务跨越多个sprint / cycle），我会选择第二种选择。
理想情况下，我会默认推荐一种策略，即将内容拆分为足够小的部分，并且sprint足够大，以便任务/功能通常可以在1个sprint内完成（即合并和部署！）。但是根据经验，我知道愿望很少能够实现 :)
最后一件事：我真的非常鼓励您不要拥有1个发布分支（永久性），而是为每个sprint / cycle创建一个新的发布分支，例如release-sprint-42，release-sprint-43等。 （无论您是基于理想git流中的develop分支还是我建议的第二种情况中的master分支创建它）。 根据我的经验，拥有永久的发布分支通常会导致丢失内容，合并问题和其他问题。 除此之外， master 和 develop 应该是永久分支。
期待这次讨论 :)
