Merge 代码合并&；用于处理多个供应商、多个功能集、交错发布日期、相同代码库的发布管理策略

我的问题是关于代码合并和发布管理策略，当您有多个供应商在不同的功能集上工作，具有不同的发布日期，但都在相同的代码库上工作时，这些策略可以最大限度地减少“代码合并痛苦”。根据现实情况改编

假设您有一个生产web应用程序，并且该系统的代码库位于代码库中（在本例中为GIT）

您的公司决定同时启动三个项目，每个项目将处理web应用程序的一组新功能（功能集1、功能集2、功能集3）。这些是相当大的功能集，将编写大量代码。该公司引进了三家不同的供应商来处理每个功能集。供应商不在同一地点。一些供应商将在现场，一些将远程工作。如上所述，每个功能集都有不同的发布日期，将在几个月内交错发布

项目开始，每个供应商将代码库的副本从GIT中的主线分支到他们自己的开发线（开发线1、开发线2、开发线3），然后每个供应商开始处理他们自己的功能集，并在进行更改时将更改检回各自的开发线

与此同时，偶尔会有一个“BAU”产品发布，它会更改web应用程序的生产代码库。每当发生这种情况时，发布经理都会通知每个供应商，以确保他们每个人都从主线“下拉并合并”到各自的开发线

我正在寻找在项目之间合并代码时最小化“代码合并痛苦”的策略，即，当一个项目的代码与另一个项目的代码合并时

你说的早和常合并？这是一个很好的策略，当你有一个单一的开发团队来开发你知道将一起发布的特性时。我很难理解，当不同的开发团队正在开发这些功能集，并且它们各自的功能集具有不同的发布日期时，如何能够“尽早且经常地合并”

一种策略是，在其中一个特性集发布到生产环境之前，绝对不要在三个不同的开发行之间进行代码合并。在这一点上，剩下的两条活跃的开发线将按照正常流程从主线“拉下并合并”。当然，这里的风险是，在这样的代码合并发生之前，可能需要几个月的并行开发

如前所述，供应商不是同一地点的，甚至不是同一开发团队的一部分。不同的开发团队之间会有一些沟通的机会，但数量不会很大。我认为这使得使用这种方法来帮助减少疼痛有些不切实际

---

欢迎任何意见。谢谢。

这些功能是向后的并且相互兼容的吗？3 x功能集彼此之间有一定的区别-当然，作为每个开发行的一部分编写的大量代码将不同于其他开发行。但是会有一些重叠,，我们当然打算在任何时候合并到主线中时进行回归测试，以准备发布候选版本。功能是否向后并且相互兼容？3 x功能集彼此之间有一定的区别-当然，作为每个开发行的一部分编写的大量代码将与其他开发行不同。然而，会有一些重叠，我们当然打算在任何时候合并到主线中，进行回归测试，以准备发布候选版本。