所以，这是我们组织当前的问题。我们有一个小团队，同时在多个项目中工作。
我们有一个简单的工作流程，我们有一个dev和master分支，其中dev是当前QA中的，master是当前正在生产（或准备生产）的。然而，当我们拥有QA中的3个特征并且其中只有一个准备好投入生产时，这会带来问题，而其他的则没有。
这将使我们樱桃挑选从一个功能到掌握的所有提交，如果项目跨越多个星期的开发，这很容易出错。我们只能在开发人员进行全面测试时向dev发送一个功能，但有时我们需要在QA中同时拥有多个功能。
是否有更适合处理这些情况的标准git工作流程？我在这个博客上阅读了一个解决方案，建议为每个项目创建开发分支，但这并不能解决我们在QA中同时拥有多个项目的情况：
更新 - 问题已更改，表明问题在于多个功能的状态，而不是最初声明的多个项目。原始答案保留在下面。
有许多竞争工作流程适用于不同的团队/项目。一个相当流行的工作流程是gitflow;它可能更适合大型项目，因为对于小型/简单项目而言似乎有点过分，但是再次为它提供了不错的工具支持。
在gitflow中，master是“已发布的内容”，develop是“现在可能发布的内容，如果我们现在要发布” - 所以在通过QA测试之前，你不会将功能合并到develop。
这确实引发了关于如何执行最佳测试的问题。显然你需要在发布之前/之前合并功能后测试develop版本，并且这些测试可能会失败并且你必须持有bug修复版本，或者回滚一个或多个功能。目标是尽可能减少发生的频率。
有了良好的基础架构，当您准备好测试该功能时，您可以将给定的功能分支部署到QA环境。为了获得最佳测试，您可以在测试之前将开发合并到功能中（之后可能撤消合并），或者在测试之前将功能重新绑定到develop（如果您不介意常规地重写功能分支）。因此，如果“一切可释放加上这一个附加功能”通过测试，那么另外一个功能将成为“可释放的东西”，您可以将其合并到develop。
在实践中，我见过的大多数项目都以某种方式妥协，依赖于功能不会相互干扰的假设（当然，这是非常乐观的，但在大多数情况下仍然可以解决）。
git中的标准是将每个项目放在自己的存储库中（尽管最近 - 而且是imo误导 - 'monorepos'的趋势）。你描述的情况是一个非常好的例子。
这并不是说你不能设计一些从一个回购中获得同样效果的分支策略 - 但如果你这样做，你可能拥有的是独立的'逻辑回购'，每个都包含自己独特的一组分支，在“一个回购”中。