我们目前正在使用SVN开发一个内部应用程序，该应用程序在插件中具有大部分功能。在我们切换git的方法中，这个应用程序引起了一些令人头疼的问题，关于在git中处理这种项目的最佳实践。
即。我们应该将每个插件放入自己的git存储库吗？这似乎是一个合乎逻辑的选择，因为插件大多不依赖于彼此而是独立（仅使用核心应用程序进行框架功能和常见功能的管理），通常由不同的人开发并偶尔弃用。然而，现在有十多个插件，还有更多的插件，构建整个项目通常需要逐个检出所有（或大多数）插件。并且似乎没有一种简单的方法可以立即查看所有这些内容，即可能需要某种“列表”，以便人们知道要获取什么，不知道什么。
另一方面，将所有内容放在一个git存储库中似乎不符合git的精神，尤其是。因为我们会携带旧的死代码并只处理一个插件需要检查很多代码（尽管那时大多数开发人员都会查看所有内容）。分支也总是分支所有东西（例如，如果插件不能单独分支，这使得分支特征的交叉测试变得困难）
一个想法是使用子模块，但我不知道开销（精神开销，我的意思是）是否大于收益（或者，我们是否获得的收益低于我们使用一对一方法所损失的收益）。
你如何在git中处理这种项目？
答案 0 :(得分：4)
这种系统（如“可写组件集合”）最好用以下方式管理：
如“true nature of submodules”中所述，您可以直接从该父项目中修改任何插件 （如果您有重复的依赖项，另请参阅Duplicate submodules with Git） 最近的Git版本附带了能够以递归方式检出父项目的所有子模块的命令。
因此，当我检查父项目并记得为每个插件调用“
git submodule init”时，我会在桌面上安装所有项目。
但你不应该记得在git submodule update --init --recursive旁边做任何事情（只需一个命令）。正如我所说，它将递归地初始化所有子模块。
然而submodules are pinned to versions，这不会导致一些更复杂的工作流程吗？
依赖管理的原则是始终引用特定版本（而不是参考“一个组件的最新代码”）。
但这并不妨碍你：
同样，true nature of submodules详细说明了这一过程。