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

Question

我们正在为并行发布的Web应用程序开发模块。我们正在尝试找出一个良好的分支策略来概述已发布的模块。这是我们目前的系统：

• Master：包含所有已发布的模块/代码（匹配生产）
• env / test：部署到测试环境的分支
• env / acceptance：部署到接受环境的分支
• env / production：部署到生产环境的分支

由于模块正在并行开发和发布，因此可以先启动一个模块，然后再发布。为了使这项工作，新模块从master的功能分支开始。此功能分支被压缩合并到env / test中，以便为新模块创建单个提交。现在困难的部分开始了。为了防止合并到env / *分支中，我们添加了一个策略来强制压缩合并。对于测试，这是正常工作的，因为它是新模块/功能合并到的第一个位置。当我们将合并压缩到接受/生产和主控时，我们松开了master和env / *分支之间的引用。我们希望保留一个参考，以便我们可以检查主要的接受程度（接受阶段未发布的模块）。

我们知道这不是最佳解决方案，但正在努力寻找更好的策略。客户真的希望保持并行开发，因为一些模块可能需要几个月的接受阶段（许多利益相关者等），一些模块可以在一周内发布。使用固定编号的发布系统会延迟某些模块，并在接受期间取消模块时引入其他问题。

Answer 1

将存储库拆分为每个模块的一个存储库（此方法用于微服务，通常在GitHub上用于开源模块）。然后每个存储库可以有单独的分支，单独的版本控制方案等。