处理30多个存储库的GIT策略

我正在考虑一种GIT策略，在主构建的基础上处理不同的构建。需要您对如何有效管理这一大规模回购/超级回购的意见

基本上，我需要一个单一的回购协议，其中有30多个子回购协议。我之所以需要这种设置，是因为每个构建迟早都会有自己的特性，而这些特性不应该影响其他构建

我的想法是为每个构建创建一个单独的分支。使用这种方法，我需要创建一个单独的构建文件夹，其中包含主构建源代码

问题是如何在不重做的情况下在构建中应用新功能？有什么办法可以这样做吗？有人知道一种有效的处理方法吗？提前谢谢

Master Base Code -+-- build 1
                  |-- build 2
                  |-- build 3
                  |-- build n..

场景1：构建特性 构建1

标题部分是旋转木马。 正文有两列 建造2

标题部分是一个图像。 正文有1列 建造2

标题部分是一个滑块。 正文有1列 -完成这些特性之后，客户机希望在其他构建中实现构建1转盘--

场景2：跨不同的构建应用构建1转盘 构建1

标题部分是旋转木马。 正文有两列 建造2

标题部分是旋转木马。 正文有1列 建造2

标题部分是旋转木马。 正文有1列 在将转盘功能合并到其他构建时，这将变得复杂，因为它们具有不同的基本代码

您可以尝试使用

基本上，在基础应用程序中，导入repo1、repo2，。。rep30作为子模块

---

现在，您可以检查特定子模块上的更新标记，同时保持所有其他子模块版本相同，并有效地为代码库创建相应的构建。

您是否考虑过只使用一个代码库，并使功能可配置？拥有这么多不同的构建似乎难以管理，不仅仅是因为git问题。嗯，是的，这是我以前的计划，知道客户如何认为不可能使用不同的env/config。谢谢，我会尝试这种方法。我已经读了一段时间了。