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