使用git中的插件维护项目

Question

我们目前正在使用SVN开发一个内部应用程序，该应用程序在插件中具有大部分功能。 在我们切换git的方法中，这个应用程序引起了一些令人头疼的问题，关于在git中处理这种项目的最佳实践。

即我们应该将每个插件放入自己的git存储库中吗？ 这似乎是一个合乎逻辑的选择，因为插件大多不依赖于彼此而是独立（仅使用核心应用程序进行框架功能和常见功能的管理），通常由不同的人开发并偶尔弃用。 然而，现在有十多个插件，还有更多的插件，构建整个项目通常需要逐个检出所有（或大多数）插件。 并且似乎没有一种简单的方法可以立即检查所有这些，即可能需要某种“列表”，以便人们知道要获得什么，不能获得什么。

另一方面，将所有内容放在一个git存储库中似乎不符合git的精神，特别是。 因为我们会携带旧的死代码并只处理一个插件需要检查很多代码（尽管那时大多数开发人员都会查看所有内容）。 分支也总是分支所有东西（例如，如果插件不能单独分支，这使得分支特征的交叉测试变得困难）

一个想法是使用子模块，但我不知道开销（精神开销，我的意思是）是否大于增益（或者，我们是否获得的收益低于我们使用一对一方法所损失的收益）。

你会如何/在git中处理这种项目？

Answer 1

这种系统（如“可写组件集合”）最好用以下方式管理：

• 每个插件都在自己的存储库中
• 一个父项目，它将所有相关插件声明为子模块。

如“ 子模块的真实性质 ”中所述，您可以直接从该父项目修改任何插件。
（如果您有重复的依赖项，请参阅使用Git复制子模块 ）最近的Git版本附带了能够以递归方式检出父项目的所有子模块的命令。

---

因此，当我检查父项目并记得为每个插件调用“ git submodule init ”时，我会在桌面上安装所有项目。

但你不应该记得在git submodule update --init --recursive （只有一个命令）旁边做任何事情。 正如我所说，它将递归初始化所有子模块。

然而， 子模块被固定到版本 ，这不会导致一些更复杂的工作流程吗？

依赖管理的原则是始终引用特定版本（而不是引用一个组件的“最新代码”）。
但这并不妨碍你：

• 在该组件中工作（从特定版本*起作为起点“）
• 承诺
• 将一个组件推送到其远程仓库
• 上升到一个级别，回到父项目中
• 提交父项目（为了引用刚修改的子模块的新版本）

同样， 子模块的真实性质详述了该过程。