Git子模块交接：主项目记录提交，外部仓库仍保留自己的历史

研发项目含有另一个项目的代码时，资料交接需要说明两者怎样关联。Git的gitsubmodules文档把子模块定义为嵌入另一仓库的仓库，且它有自己的历史；包含它的仓库称为superproject，即主项目。[1] 这种嵌入关系不是把两边历史揉成一份，反而保留了分别演进的基础。

文档解释，主项目的工作树可以容纳另一个项目的工作树，同时让两个项目历史保持独立。这为理解外部项目持续开发提供了背景：外部仓库后来产生新提交，与主项目此刻采用哪个提交，是相连但需要分别说明的事项。只知道外部项目更新了，不能直接补记主项目也已采用更新。

关联到具体版本的是gitlink。原文说，主项目树中的gitlink条目包含一个提交的对象名称，表示主项目期望子模块工作目录处于哪个提交。因此，它记录的是明确的版本位置，而不是外部项目的宣传名称，也不是一条始终自动追随最新内容的泛链接。本文没有读取或修改任何真实研发仓库。

另一份资料是.gitmodules。文档将它与子模块名称和路径的对应联系起来，并举URL设置为例，说明从哪里取得子模块。来源位置与提交对象名在这里分别回答哪里取得和采用哪一版。即使同一个URL仍然可用，也不能仅凭地址未变，推定外部仓库内容或主项目采用的提交始终相同。

原文特别说明，子模块可以固定到某一版本，使另一个项目独立开发而不影响主项目，并让主项目在需要时才转向新版本。这是文档对依赖关系的描述，不是对任何交付品已经锁定、同步或验证完成的保证。版本关联存在，与实际文件已核对，是不同的工作证据。

本地内容还可能呈现另一种状态。FORMS一节把deinitialized子模块描述为仍有gitlink与.gitmodules条目，却没有子模块工作目录，其预期目录为空。这个定义说明，主项目保存跟踪关系与当前本地展开内容不是同一件事。本文只采用该状态描述，不提供取消初始化、删除、恢复或权限配置步骤。

对研发资料交接，独立仓库历史、明确提交、取得位置与工作目录状态，能够共同说明依赖对象。它们不能只剩下一句已包含外部代码，也不能替代工程验收、许可或权属判断。本文依据Git公开文档的DESCRIPTION与FORMS概念，文档版本更新线索不作首次发布日期；没有执行命令、下载代码或更改生产配置。