Git工作流标准，用于处理开发分支中的多个项目

因此，这是我们组织当前的问题。我们有一个小团队，同时在多个项目中工作

我们有一个简单的工作流，我们有一个dev和master分支，其中dev是当前在QA中的，master是当前在生产（或准备生产）中的。然而，当我们在QA中有3个特性，并且其中只有一个已经准备好投入生产，而其他的还没有准备好时，这就带来了问题

这将使我们从一个特性中挑选出所有提交来掌握，如果项目跨越数周的开发，这很容易出错。我们只能在QA中对一个特性进行了全面测试后才能将其发送给开发人员，但有时我们需要在QA中同时具有多个特性

是否有更适合处理这些情况的标准git工作流？我在这个博客上读到一个建议为每个项目创建开发分支的解决方案，但这并不能解决我们在QA中同时有多个项目的情况：

更新-问题已更改，表明问题与多个功能的状态有关，而不是与最初所述的多个项目有关。原始答案保留在下面

---

有许多相互竞争的工作流适用于不同的团队/项目。一个相当流行的工作流是gitflow；它可能更适合于大型项目，因为对于小型/简单的项目来说，它似乎有点过分，但同样也有不错的工具支持

在gitflow中，

master

是“已经发布的内容”，而

develope

是“如果我们现在就发布，那么现在可能发布的内容”-因此在通过QA测试之前，您不会将功能合并到

develope

这确实引发了关于如何执行最佳测试的问题。显然，您需要在特性合并后/发布前测试

develope

版本，这些测试可能会失败，您必须暂停发布以进行错误修复，或者回滚一个或多个特性。我们的目标是尽量减少这种情况发生的频率

有了一个好的基础设施，当您准备测试某个特性时，您可以潜在地将该特性分支部署到QA环境中。为了获得最好的测试，您可以在测试之前将develop合并到功能中（可能在测试之后撤消合并），或者在测试之前将功能重新设置为

develop

（如果您不介意经常重写功能分支）。因此，如果“所有可发布的功能加上这一附加功能”通过测试，那么这一附加功能将成为“可发布的功能”，您可以将其合并到

develope

在实践中，我所看到的大多数项目都以某种方式进行了妥协，依赖于功能不会相互干扰的假设（当然，这是过分乐观的，但在大多数情况下可能仍然有效）

---

git中的标准是将每个项目放在自己的存储库中（尽管最近出现了“monorepos”这一错误趋势，但在我看来也是如此）。您所描述的情况就是一个很好的例子

---

这并不是说你不能设计出某种分支策略来从一次回购中获得同样的效果——但如果你这样做，你可能会得到的是单独的“逻辑回购”，每个“逻辑回购”在“一次回购”中包含自己独特的分支集。

对不起，只是现在我注意到我错误地描述了“功能”“作为项目。我指的是QA中的3个不同功能，而不是3个不同的项目。已经更正了最初的帖子。