将多个并行特性发布到同一个应用程序中的Git分支策略

Question

我们正在为一个并行发布的web应用程序开发模块。我们正试图找出一个好的分支策略，以保持对发布模块的概述。这是我们目前的制度：

• 主:包含所有已发布的模块/代码(匹配生产)
• env/test:部署到测试环境中的分支
• 环境/验收:部署到验收环境中的分支
• 环境/生产:部署到生产环境中的分支

由于模块是并行开发和发布的，一个模块可以一个接着一个地启动，并在更早的时候发布。为了使这一工作，一个新的模块开始从一个功能分支从主人。这个特性分支被压缩到env/test中，以便为新模块创建一个提交。现在困难的部分开始了。为了防止合并到env/*分支中，我们增加了一个强制合并的策略。对于测试来说，这是正确工作的，因为它是第一个将新模块/特性合并到的地方。当我们合并到接受/生产和掌握中时，我们就失去了主和env/*分支之间的引用。我们想要保持一个引用，以便我们可以检查有多少验收是先进的(未发布的模块在验收阶段)。

我们知道这不是最好的解决方案，但我们正在努力想出一个更好的策略。客户端非常希望维护并行开发，因为有些模块可能需要几个月的接受阶段(许多涉众等等)，而有些模块可以在一周内发布。使用固定编号的发布系统会延迟某些模块，当模块在验收过程中被取消时会引发其他问题。

Answer 1

将存储库划分为每个模块的一个存储库(这种方法用于微服务，通常用于开源模块的GitHub )。然后，每个存储库可以有独立的分支、独立的版本控制方案等。