我的问题是关于代码合并和发布管理策略，这些策略可以最大限度地减少“代码合并难度”，因为当您使用具有不同发布日期但同时处理相同代码库的不同功能集的供应商工作时。改编自现实世界的情况..
假设您有一个生产Web应用程序，该系统的代码库位于代码存储库中（在本例中为GIT）。
贵公司决定同时启动三个项目，每个项目都将处理Web应用程序的一组新功能（功能集1，功能集2，功能集3）。这些是相当大的功能集，将编写大量代码。该公司引入了三个不同的供应商来处理每个功能集。供应商不在同一地点。一些供应商将在现场，一些将远程工作。如上所述，每个功能集都有不同的发布日期，在几个月内会错开。
该项目启动，每个供应商将代码库的副本从GIT中的主线分支到他们自己的开发线（开发线1，开发线2，开发线3），并且每个供应商开始工作他们自己的功能集，检查更改回到他们不同的开发线。
与此同时，偶尔会出现“BAU”产品版本，它会更改Web应用程序的生产代码库。每当发生这种情况时，发布经理会通知每个供应商确保他们每个人从主线“拉下并合并”到他们独特的开发线。
我正在寻找在项目之间合并代码时最小化“代码合并难度”的策略，即，当一个项目的代码与另一个项目的代码合并时。
早期合并，经常你说？如果您有一个开发团队正在处理您知道将全部一起发布的功能，那么这是一个很好的策略。我很难看到当不同的开发团队正在处理功能集时，如何“早期和经常合并”，并且各自的功能集具有不同的发布日期。
一种策略是在三个不同的开发线之间完全没有代码合并，直到其中一个功能集已经发布到生产中。此时，剩下的两条活动开发线将按照正常流程从主线“拉下并合并”。这里的风险当然是，在这样的代码合并发生之前可能需要数月的并行开发。
如上所述，供应商不在同一个开发团队中，也不是同一个开发团队的一部分。不同的开发团队之间将有一些交流的机会，但不是很大。我认为这使得使用Feature Toggles对于帮助减少痛苦有点不切实际。
欢迎任何建议。感谢。