Git 插件存储库的结构，作为子模块包含在其他存储库中

我面临以下挑战。 有一个泛型类ClassA。它有childs ClassB ClassC和其他类，每个类都可以有多个childs，这些都是插件。这些将是可重用的插件，因此我希望将它们保存在存储库中，以共享项目的访问。此外，这些插件在项目中使用时将被更改-一些错误/问题将被修复，新方法将被添加。因此，我希望能够将更改从项目推回到插件存储库，以便始终有实际的代码。 我想在我的项目中使用这些插件。因此，我考虑了3种可能性：

A类为单独回购。ClassB、ClassC等也是独立的存储库，并使用ClassA repo作为子模块。然后，文件夹结构将如下所示：

b类回购
|----甲级/
|---+B类/
|---+插件/
|----插件B_1/
|---- ...
|----插件\u B\u N/

类似的C类：

c类回购
|----甲级/
|---+C类/
|---+插件/
|----插件C_1/
|---- ...
|----插件\u C\u N/

然后，我可以将ClassB和ClassC存储库作为子模块->包含到我的主存储库文件夹中，但会有代码重复（ClassA在两个目录中共享）。我使用LabVIEW和TestStand，因此当TestStand加载ClassB/ClassC的方法时，它会遇到依赖性问题——因为从多个位置加载的内存中会有相同的方法。这是TestStand的“特性”，我们不得不接受它——但这意味着第1种方法不太合适

具有与第一种方法类似的结构，但主要项目将包括从B类和C类项目构建。此构建将以与repos中的文件夹结构相同的方式完成，但它们将按如下方式复制到主项目：

|----ClassA/
|---+B类/
|---+插件/
|----插件B_1/
|---- ...
|----插件/
|---+C类/
|---+插件/
|----插件C_1/
|---- ...
|----插件\u C\u N/

因此，ClassA将只出现一次。在复制ClassB/C版本时，ClassA文件夹将被彼此“重写”——但这是可以的。 什么是NOK，是： -插件的更改应该在repos中完成——因为我不能将构建的代码复制回存储库； -每次更改之后，都应该进行构建，做额外的工作——特别是当插件不“稳定”并且经常需要更改时

所有类/插件都保存在单个存储库中。其结构如下：

|----ClassA/
|---+B类/
|---+插件/
|----插件B_1/
|---- ...
|----插件
|---+C类/
|---+插件/
|----插件C_1/
|---- ...
|----插件\u C\N/
... 
|---+类别/
|---+插件/
|----插件1/
|---- ...
|----插件\u N\u N/

然后，该存储库将作为子模块包含到主项目存储库中。 这里的问题是项目不需要所有插件；最好以某种方式过滤掉它们。 在这里，我看到三种方式： 3.1. 从带有插件的主repo中，我将创建fork->并从中删除不需要的插件。然后，分叉回购将作为子模块包含到主项目中。 缺点是，在更新插件时，我想将更改推送到主插件repo。但在这种情况下，我需要将其推送到forked repo，然后从forked推到main->并“手动”处理更改，b/c forked repository中移除的插件（这些插件存在于main repository中）。 3.2. 与之前类似，但不同的是，在主回购中不会有分支机构，而是单独的分支机构。 3.3. 插件库包含在主项目中，但主项目包含一些设置，可以从子模块中筛选出不需要的插件。在主回购级别上，子模块外部的子模块的某种.gitignore。但我猜这样的选项是不存在的——如果主repo包含子模块的.gitignore文件，子模块repo无论如何都会跟踪子模块中更改的文件。因此，很难处理从子模块内部推送到主插件repo的操作

有没有办法很好地解决这个问题？我相信这是一些常见的情况，但我现在找不到解决办法。。。

---

提前多谢

不幸的是，架构问题无法真正得到回答，因此让我在评论中分享一下想法。：）标准的建议是选择组合而不是继承。如果Plugin_A_1不依赖于基类A，而只是实现了IPluginA接口，那么您的一些问题就解决了。第二个标准建议是，GIT并不是一个很好的包/发布/版本管理工具，无法协调跨项目使用的插件版本。这就是为什么会有NPM/warn/rubygems/python包。如果labview有类似的功能，从长远来看，您可能会发现它更好。也就是说，您在回购协议中有专门的、独立的、版本化的插件包。您可以根据需要对其进行版本/分支，并将正确的版本插入任意数量的项目中。我想这意味着一个VIPM包？VIPM包有一个缺点-库将安装在LabVIEW中，然后所有VIs都将引用该库。但若发布新版本，那个么所有使用该库的Vi都将引用更新的库。