Git 项目中处理子模块的方法与策略
1. 背景与问题提出
在软件开发领域，版本控制系统（VCS）起着至关重要的作用。像 KDE 项目这样使用多千兆字节 SVN 仓库的项目，以往鼓励部分检出，但这种方式在分布式 VCS（如 Git）中并不适用。因为在 Git 里，每次下载都会获取所有文件的所有版本，其当前架构对部分检出的支持并不理想。
目前，KDE 项目正考虑从 SVN 迁移到 Git，其中子模块是主要争议点。将整个 KDE 仓库导入 Git 后仍有几GB大小，即便开发者只想处理一个应用，也得拥有所有数据的副本。而且每个应用都依赖一个或多个 KDE 核心库，不能为每个应用单独创建仓库。所以，KDE 若想成功迁移到 Git，需要一种替代大型单体仓库简单部分检出的方法，例如曾有将 KDE 代码库拆分为约500个独立仓库的实验性导入。
2. 直接导入代码到项目的方案
一种简单的方案是将库导入到自己项目的子目录中，后续若要更新库，可复制新的文件集。这种方法有诸多优点：
- 不会意外使用错误的库版本。
- 易于解释和理解，仅依赖日常的 Git 功能。
- 无论外部库使用 Git、其他 VCS 还是无 VCS 维护，工作方式都相同。
- 应用仓库自给自足，git clone应用时会包含所需的一切。
- 即便没有库仓库的提交权限，也能在自己的仓库中对库应用特定于应用的补丁。
- 对应用分支时，库也会相应分支。
- 使用git pull -s subtree命令的子树合并策略更新库版本，就像更新项目的其他部分一样简单。
