因此，这是我们组织中的当前问题。我们有一个小型团队，正在同时从事多个项目。
我们有一个简单的工作流程，有一个dev和master分支，其中dev是质量检查中当前使用的内容，而master是当前正在生产中（或准备投入生产）的内容。但是，当我们在质量检查中拥有3个功能，而其中只有一个准备好投入生产而其他功能还没有准备就绪时，这就带来了问题。
这将使我们从一个功能中挑选所有提交提交给主控，如果该项目跨越多个开发周期，则容易出错。我们只有在功能经过质量检查后才能向开发人员发送功能，但是有时我们需要同时在质量检查中拥有多个功能。
是否有一个更适合处理这些情况的标准git工作流程？我在此博客上阅读了一个解决方案，该解决方案建议为每个项目创建开发分支，但这不能解决我们必须同时在质量检查中包含多个项目的情况：
答案 0 :(得分：1)
更新-问题已更改，以指示问题出在多个功能的状态上，而不是最初陈述的多个项目。原始答案保存在下面。
有许多竞争的工作流程可用于不同的团队/项目。 gitflow是一种非常流行的工作流程；它可能更适合大型项目，因为对于小型/简单项目而言似乎有些过时了，但是再次有不错的工具支持。
在gitflow中，master是“已发布的内容”，而develop是“如果我们现在要进行发布，则可能会立即发布的内容”-这样就不会合并develop的功能，直到它通过了质量检查。
这确实引发了有关如何执行最佳测试的问题。显然，在将功能合并到/中之前，您需要测试develop版本，然后才能发布这些测试，并且这些测试可能会失败，并且您必须持有该版本的错误修正，或者滚动一个或返回更多功能。目的是最大程度地减少这种情况的发生。
有了良好的基础架构，当您准备测试该功能时，就可以将其功能分支部署到QA环境。为了获得最好的测试，您可以在测试之前将开发合并到功能中（可能然后在之后取消合并），或者在测试之前将功能重新设置为develop（如果您不介意重写功能分支）通常）。因此，如果“所有可释放的东西加上此一项附加功能”通过测试，则该另外一个功能将变为“可释放的东西”，您可以将其合并到develop。
在实践中，我看到的大多数项目都以某种方式折衷，这是基于这样的假设，即功能不会互相干扰（当然，过分乐观，但在大多数情况下仍然可行）
git中的标准是将每个项目放在其自己的存储库中（尽管最近-并且imo被误导了-'monorepos'的趋势）。您描述的情况就是一个很好的例子。
这并不是说您不能设计出一种可以从一个存储库中获得相同效果的分支策略-但是，如果这样做，您可能会得到的是单独的'逻辑存储库'每个都在“一个仓库”内包含自己独特的分支集。