git流跟踪项目中大特性划分的可伸缩模式？

Question

我负责一个由大型存储库(包括子模块)组成的项目的基础设施。

项目组成功地实现了git流(如描述的这里)以支持版本化的版本。简单地说，这是develop、master和staging-$version分支。日常工作特性的分支，并进入develop。

有时，多个版本同时发生，通常多个版本需要同时支持。

我现在需要支持这个模型中的一个大硬件集成功能(即支持一个新的wifi芯片)的分裂。由于监管原因，功能切换是不够的。我需要支持这个项目的一个版本，在这个版本中，没有构建wifi功能，也没有包含在源中。源必须是可用的，并且可以追溯到最终的二进制版本。这很蠢吗？是。我能做点什么吗？不是的。与FCC谈判超出了我的工资水平。

非wifi相关的工作仍然必须包括在wifi和非wifi版本的项目。

天真的解决方案是这样的一组分支：

• develop
• develop-wifi
• master
• master-wifi
• staging-$version (现在可以从develop或develop-wifi分支)

只使用来自develop->develop-wifi的单向合并处理无关的开发。

显然，这是没有规模的。当我们需要在6个月内支持蓝牙时会发生什么，但这意味着该项目只有wifi、蓝牙、wifi+bluetooth和无射频版本？

为了解决这个问题，我已经花了很多时间，但是我缺少一个很好的可伸缩的模型来支持像这样的大型功能划分。也许没有一个好的答案(这是推高了git的范围)。我对这个主题的所有搜索结果都与git流教程和管理特性分支相混淆，这是一个典型的期望是一切都向上游移动的地方。

有人能推荐一个好的模式来以更可伸缩的方式来处理这个问题吗？

Answer 1

最好的设计，我登陆后，寻求明确的规则，我们必须遵守的是插入编译时功能标志。

因此，这是一个问题的最终答案，但最终却最适用于我们的具体用例。TTT关于将特性功能构建为可选包的评论实际上与我认为的具有额外抽象级别的体系结构相同，但幸运的是，遵从性团队实际上并没有那么武断。

我仍然没有找到一个好的以分支为中心的解决方案，所以我将把这个问题保留下来，但是似乎“将相同的补丁应用于两个越来越不同的分支”的概念在核心级别上并没有真正的意义，所以我并不乐观地认为其中有一个好的解决方案。